Deux circuits, un routeur. Un DMVPN double cloud qui utilise les deux liens

La plupart des sites distants dotés de deux circuits WAN n'en utilisent qu'un. Le second reste en secours, payé chaque mois et sollicité seulement quand le premier tombe, ce qui est aussi la première fois que quelqu'un découvre si le failover fonctionne vraiment. Avec DMVPN et BGP, vous pouvez faire tourner les deux circuits en permanence, basculer de l'un à l'autre sans y penser, et prouver que les deux transportent du trafic. Voici la méthode.

Un bref rappel sur DMVPN

Nous faisons tourner BGP au-dessus de DMVPN (mGRE, NHRP, IPsec), de sorte qu'ajouter ou perdre un site est un événement de routage plutôt qu'une reconfiguration.

Le design habituel pour la redondance est deux hubs sur un seul cloud. Cela protège contre la panne d'un hub. Cela ne fait rien pour un spoke avec deux circuits, parce que l'unique interface tunnel du spoke prend sa source sur l'un d'eux.

Le design double cloud

La solution est un second cloud DMVPN indépendant, dont la source est le second circuit. L'objection habituelle est que cela implique de nouvelles adresses publiques, de nouvelles règles de firewall et une nouvelle configuration de hub. Ce n'est pas obligatoire, si vous séparez les clouds avec une tunnel key. GRE transporte la clé dans son en-tête, donc le hub peut terminer deux tunnels multipoint sur la même interface physique et la même adresse publique tout en les distinguant.

Sur le hub, le second cloud est une copie du premier avec son propre sous-réseau de tunnel, son NHRP network ID et sa clé :

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

Le mot-clé shared sur le profil de protection compte quand deux tunnels partagent une source : sans lui, les security associations IPsec des deux tunnels entrent en collision.

Sur le spoke, Tunnel1 prend sa source sur le premier circuit et Tunnel2 sur le second, chacun pointant vers la même adresse de hub avec sa propre clé. Rien ne change pour aucun autre spoke.

Faites en sorte que le routage utilise les deux

Deux tunnels vous donnent deux sessions BGP vers le hub, et donc deux chemins vers chaque destination. Par défaut, BGP n'en choisit toujours qu'un. Deux réglages changent cela :

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

Les deux sessions doivent aboutir dans la même table de routage pour que les chemins soient réellement égaux. Assurez-vous ensuite que le hash de forwarding répartit les flux et non des paires source et destination entières. Un hash qui inclut les ports de couche 4 place les flux parallèles entre les deux mêmes hôtes sur des circuits différents, ce qui est exactement ce que vous voulez pour les backups et la réplication :

ip cef load-sharing algorithm include-ports source destination

Prouvez-le, ne le supposez pas

Un show ip route qui liste deux next hops prouve que le multipath est configuré. Il ne prouve pas que le trafic utilise les deux circuits. La seule preuve acceptable est un test de débit avec plusieurs flux parallèles qui atteint, dans chaque direction, plus que ce qu'un seul circuit pourrait transporter, pendant que vous regardez les compteurs des deux interfaces physiques monter ensemble :

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

Si une seule interface fait tout le travail, regardez le hash et vérifiez que les deux chemins BGP sont réellement installés.

Dimensionnez sur le moteur crypto, pas sur la licence

Chaque routeur a un débit licencié et un plafond de chiffrement réel, et les deux ne sont pas identiques. Le plafond dépend du matériel crypto, des tailles de paquets et de tout ce que le routeur fait par ailleurs. Mesurez-le avec un trafic réaliste, pas avec la taille de paquet idéale d'une fiche technique, et dimensionnez d'après ce que vous avez mesuré.

Sur notre backbone, cette valeur mesurée est d'environ 11 Gbit/s de trafic chiffré par hub. Quand un client a besoin de plus entre ses sites, nous n'attendons pas une machine plus grosse : nous répartissons le trafic sur plusieurs hubs avec de l'equal-cost multipath, ce qui porte la capacité chiffrée à 30 à 40 Gbit/s. Le même principe qui fait qu'un site distant utilise ses deux circuits fait qu'un backbone utilise tous ses hubs.

Nous utilisons des routeurs virtuels pour les sites calmes et des routeurs matériels pour les sites chargés.

Des hubs redondants qui ne se mettent pas en travers

Un hub de secours doit rester silencieux jusqu'à ce qu'on en ait besoin. Donnez-lui son propre AS BGP ou une dépréférence sortante délibérée pour que les spokes préfèrent le primaire, et utilisez BFD sur les tunnels pour qu'un primaire mort soit détecté en quelques secondes plutôt qu'au hold timer BGP. Les spokes basculent alors par le routage seul. Personne ne touche un routeur de site distant parce qu'un hub a changé.

Une checklist pour votre propre WAN

• Chaque site avec deux circuits utilise-t-il les deux, et pouvez-vous le montrer avec un test de débit ?
• Les deux clouds sont-ils séparés par tunnel key, avec une protection IPsec shared ?
• Le BGP multipath est-il activé et le hash de forwarding inclut-il les ports ?
• BFD tourne-t-il sur chaque tunnel ?
• Connaissez-vous votre plafond de chiffrement mesuré par hub, pas celui de la licence ?
• Une panne de hub vous obligerait-elle à toucher un seul spoke ?

Nous exploitons ce design dans nos datacenters d'Athènes, d'Amsterdam et de Toronto, avec des hubs redondants dans chacun, et nous construisons la même chose pour les clients qui veulent relier leurs propres bureaux à leur plateforme. Si vous souhaitez de l'aide pour concevoir le vôtre, nous serons heureux d'en parler.

Parler à un ingénieur

Related

Sur le même sujet : Backbone chiffré multi-sites : le maillage DMVPN · Connectivité privée : passerelles VPN et lignes louées · Supervision réseau et preuves