Zwei Leitungen, ein Router. Dual-Cloud-DMVPN, das beide Links nutzt
Bauen Sie eine zweite DMVPN-Cloud mit Tunnel Keys, betreiben Sie BGP Multipath über beide WAN-Leitungen, und dimensionieren Sie die verschlüsselte Kapazität nach der Crypto Engine, nicht nach der Lizenz.

Die meisten Niederlassungen mit zwei WAN-Leitungen nutzen eine davon. Die zweite steht als Reserve bereit, wird jeden Monat bezahlt und nur dann beansprucht, wenn die erste ausfällt, was zugleich der erste Moment ist, in dem jemand erfährt, ob das Failover wirklich funktioniert. Mit DMVPN und BGP können Sie beide Leitungen dauerhaft betreiben, ohne Nachdenken zwischen ihnen umschalten und beweisen, dass beide Datenverkehr tragen. Hier ist die Methode.
Eine kurze Auffrischung zu DMVPN
Wir betreiben BGP über DMVPN (mGRE, NHRP, IPsec), sodass das Hinzufügen oder der Verlust eines Standorts ein Routing-Ereignis ist und keine Neukonfiguration.
Das übliche Design für Redundanz sind zwei Hubs in einer Cloud. Das schützt vor dem Ausfall eines Hubs. Für einen Spoke mit zwei Leitungen bringt es nichts, weil das einzige Tunnel-Interface des Spokes von einer der beiden ausgeht.
Das Dual-Cloud-Design
Die Lösung ist eine zweite, unabhängige DMVPN-Cloud, die von der zweiten Leitung ausgeht. Der übliche Einwand lautet, das bedeute neue öffentliche Adressen, neue Firewall-Regeln und neue Hub-Konfiguration. Das muss es nicht, wenn Sie die Clouds mit einem Tunnel Key trennen. GRE trägt den Key in seinem Header, also kann der Hub zwei Multipoint-Tunnel auf demselben physischen Interface und derselben öffentlichen Adresse terminieren und sie trotzdem auseinanderhalten.
Auf dem Hub ist die zweite Cloud eine Kopie der ersten mit eigenem Tunnel-Subnetz, eigener NHRP Network ID und eigenem 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
Das Schlüsselwort shared am Protection Profile ist wichtig, wenn zwei Tunnel eine Quelle teilen: Ohne es kollidieren die IPsec Security Associations der beiden Tunnel.
Auf dem Spoke geht Tunnel1 von der ersten Leitung aus und Tunnel2 von der zweiten, beide zeigen auf dieselbe Hub-Adresse mit ihrem eigenen Key. Für keinen anderen Spoke ändert sich etwas.
Bringen Sie das Routing dazu, beide zu nutzen
Zwei Tunnel geben Ihnen zwei BGP-Sessions zum Hub und damit zwei Pfade zu jedem Ziel. Standardmäßig wählt BGP trotzdem einen aus. Zwei Einstellungen ändern das:
router bgp 65010
address-family ipv4
maximum-paths 2
maximum-paths ibgp 2
Beide Sessions sollten in derselben Routing-Tabelle landen, damit die Pfade wirklich gleichwertig sind. Stellen Sie dann sicher, dass der Forwarding-Hash Flows verteilt und nicht ganze Quell-Ziel-Paare. Ein Hash, der Layer-4-Ports einbezieht, legt parallele Flows zwischen denselben zwei Hosts auf unterschiedliche Leitungen, und genau das wollen Sie für Backups und Replikation:
ip cef load-sharing algorithm include-ports source destination
Beweisen Sie es, nehmen Sie es nicht an
Ein show ip route, das zwei Next Hops auflistet, beweist, dass Multipath konfiguriert ist. Es beweist nicht, dass der Datenverkehr beide Leitungen nutzt. Der einzige akzeptable Beweis ist ein Durchsatztest mit mehreren parallelen Flows, der in jeder Richtung mehr erreicht, als eine der Leitungen allein tragen könnte, während Sie zusehen, wie die Zähler auf beiden physischen Interfaces gemeinsam steigen:
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
Wenn ein Interface die ganze Arbeit macht, sehen Sie sich den Hash an und prüfen Sie, ob beide BGP-Pfade wirklich installiert sind.
Dimensionieren Sie nach der Crypto Engine, nicht nach der Lizenz
Jeder Router hat einen lizenzierten Durchsatzwert und eine reale Verschlüsselungsgrenze, und die beiden sind nicht dasselbe. Die Grenze hängt von der Crypto-Hardware, den Paketgrößen und davon ab, was der Router sonst noch tut. Messen Sie sie mit realistischem Datenverkehr, nicht mit der günstigsten Paketgröße aus einem Datenblatt, und dimensionieren Sie nach dem, was Sie gemessen haben.
Auf unserem Backbone liegt dieser gemessene Wert bei etwa 11 Gbit/s verschlüsseltem Datenverkehr pro Hub. Wenn ein Kunde zwischen Standorten mehr braucht, warten wir nicht auf eine größere Maschine: Wir verteilen den Datenverkehr mit Equal-Cost Multipath auf mehrere Hubs, was die verschlüsselte Kapazität auf 30 bis 40 Gbit/s bringt. Dasselbe Prinzip, das eine Niederlassung beide Leitungen nutzen lässt, lässt ein Backbone alle seine Hubs nutzen.
Wir setzen virtuelle Router für ruhige Standorte ein und Hardware-Router für die stark ausgelasteten.
Redundante Hubs, die nicht im Weg stehen
Ein Standby-Hub sollte ruhig bleiben, bis er gebraucht wird. Geben Sie ihm ein eigenes BGP-AS oder eine bewusst niedrigere ausgehende Präferenz, damit die Spokes den primären bevorzugen, und nutzen Sie BFD auf den Tunneln, damit ein toter primärer Hub in Sekunden erkannt wird statt erst beim BGP Hold Timer. Die Spokes schalten dann allein über das Routing um. Niemand fasst einen Niederlassungsrouter an, weil sich ein Hub geändert hat.
Eine Checkliste für Ihr eigenes WAN
- Nutzt jeder Standort mit zwei Leitungen beide, und können Sie das mit einem Durchsatztest zeigen?
- Sind die beiden Clouds per Tunnel Key getrennt, mit
sharedIPsec Protection? - Ist BGP Multipath aktiviert, und bezieht der Forwarding-Hash die Ports ein?
- Läuft BFD auf jedem Tunnel?
- Kennen Sie Ihre gemessene Verschlüsselungsgrenze pro Hub, nicht die lizenzierte?
- Würde ein Hub-Ausfall Sie zwingen, auch nur einen Spoke anzufassen?
Wir betreiben dieses Design in unseren Rechenzentren in Athen, Amsterdam und Toronto, mit redundanten Hubs an jedem Standort, und bauen dasselbe für Kunden, die ihre eigenen Büros an ihre Plattform anbinden möchten. Wenn Sie Hilfe beim Entwurf Ihres eigenen wünschen, sprechen wir gern mit Ihnen.
Related
Verwandt: Verschlüsseltes Multi-Site-Backbone: das DMVPN-Mesh · Private Anbindung: VPN-Gateways und Standleitungen · Netzwerk-Monitoring und Nachweise
Veröffentlicht am 16. Oktober 2026.
Alle Notizen aus der Praxis