Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Im Artikel " Entwerfen für die Notfallwiederherstellung mit privatem ExpressRoute-Peering" haben wir die Notwendigkeit einer Sicherungsverbindungslösung bei Verwendung von privatem ExpressRoute-Peering erörtert. Darüber hinaus wurde erläutert, wie georedundante ExpressRoute-Schaltkreise für hohe Verfügbarkeit verwendet werden. In diesem Artikel wird erläutert, wie Ein Standort-zu-Standort-VPN (S2S) als Sicherung für private ExpressRoute-Peering verwendet und verwaltet wird.
Hinweis
Die Verwendung von Site-to-Site-VPN als Sicherungslösung für ExpressRoute-Konnektivität wird nicht empfohlen, wenn Sie latenzempfindliche, unternehmenskritische oder bandbreitenintensive Workloads verwenden. In solchen Fällen ist es ratsam, für die Notfallwiederherstellung mit ExpressRoute Resilienz über mehrere Standorte zu entwerfen, um eine maximale Verfügbarkeit sicherzustellen.
Im Gegensatz zu georedundanten ExpressRoute-Schaltkreisen können Sie nur ExpressRoute- und VPN-Notfallwiederherstellungskombinationen in einem aktiv-passiven Setup verwenden. Eine große Herausforderung bei der Verwendung einer Sicherungsnetzwerkkonnektivität im passiven Modus besteht darin, dass die passive Verbindung häufig zusammen mit der primären Verbindung fehlschlägt. Der häufige Grund für die Fehler der passiven Verbindung ist mangelnde aktive Wartung. Daher liegt der Schwerpunkt in diesem Artikel darauf, wie eine S2S-VPN-Konnektivität überprüft und aktiv verwaltet wird, die ein privates ExpressRoute-Peering sichert.
Hinweis
Wenn eine bestimmte Route über ExpressRoute und VPN angekündigt wird, bevorzugt Azure das Routing über ExpressRoute.
In diesem Artikel erfahren Sie auch, wie Sie die Konnektivität sowohl aus Azure-Perspektive als auch auf der lokalen Netzwerk-Edgeseite überprüfen. Die Möglichkeit, von beiden Seiten zu validieren, hilft unabhängig davon, ob Sie die standortgebundenen Netzwerkgeräte verwalten, die mit den Microsoft-Netzwerkentitäten verbunden sind.
Beispieltopologie
In unserer Einrichtung verfügen wir über ein lokales Netzwerk, das über einen ExpressRoute-Schaltkreis und eine S2S-VPN-Verbindung mit einem virtuellen Azure Hub-Netzwerk verbunden ist. Das Azure-Hub-VNet ist wiederum mittels Peering mit einem Spoke-VNet verbunden, wie in der folgenden Abbildung dargestellt:
In diesem Setup wird die ExpressRoute-Verbindung auf einem Paar von Edgeroutern des Kunden (Customer Edge, CE) am lokalen Standort beendet. Das lokale Netzwerk ist mit den CE-Routern über ein Paar von Firewalls verbunden, die im Leader-Follower-Modus ausgeführt werden. Das S2S-VPN wird direkt auf den Firewalls beendet.
In der folgenden Tabelle sind die wichtigsten IP-Präfixe der Topologie aufgeführt:
| Entität | prefix |
|---|---|
| Lokales LAN | 10.1.11.0/25 |
| Virtuelles Azure Hub-Netzwerk | 10.17.11.0/25 |
| Virtuelles Azure-Spoke-Netzwerk | 10.17.11.128/26 |
| Lokaler Testserver | 10.1.11.10 |
| Spoke-Netzwerk virtuelle Test-VM | 10.17.11.132 |
| Primäre ExpressRoute-Verbindung P2P-Subnetz | 192.168.11.16/30 |
| Sekundäre ExpressRoute-Verbindung P2P-Subnetz | 192.168.11.20/30 |
| PRIMÄRE BGP-Peer-IP des VPN-Gateways | 10.17.11.76 |
| SEKUNDÄRE BGP-Peer-IP des VPN-Gateways | 10.17.11.77 |
| IP-Adresse des lokalen Firewall-VPN-BGP-Peers | 192.168.11.88 |
| Primäre CE-Router-Schnittstelle in Richtung Firewall-IP | 192.168.11.0/31 |
| Firewall-I/F für primäre CE-Router-IP | 192.168.11.1/31 |
| Sekundäre CE-Router-I/F für Firewall-IP | 192.168.11.2/31 |
| Firewall-I/F für sekundäre CE-Router-IP | 192.168.11.3/31 |
In der folgenden Tabelle sind die ASNs der Topologie aufgeführt:
| Autonomes System | ASN |
|---|---|
| On-premises | 65020 |
| Microsoft Enterprise Edge | 12076 |
| Virtuelles Netzwerk GW (ExR) | 65515 |
| Virtuelles Netzwerk GW (VPN) | 65515 |
Hohe Verfügbarkeit ohne Asymmetrischkeit
Konfigurieren für hohe Verfügbarkeit
Im Artikel Konfigurieren von ExpressRoute- und Site-zu-Site-Koexistenzverbindungen wird erläutert, wie Sie expressRoute- und S2S-VPN-Verbindungen einrichten. Wie wir bei der Entwicklung für hohe Verfügbarkeit mit ExpressRoute erwähnt haben, stellt unser Setup sicher, dass netzwerkredundanzt ist, um jeden einzelnen Fehlerpunkt bis zu den Endpunkten zu beseitigen, wodurch die hohe Verfügbarkeit von ExpressRoute verbessert wird. Darüber hinaus sind sowohl die primären als auch die sekundären Verbindungen der ExpressRoute-Schaltkreise aktiv und werben die lokalen Präfixe auf die gleiche Weise über beide Verbindungen an.
Die lokale Routenanzeige des primären CE-Routers über die primäre Verbindung des ExpressRoute-Schaltkreises wird wie folgt angezeigt (Junos-Befehle):
user@SEA-MX03-01> show route advertising-protocol bgp 192.168.11.18
Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
Die lokale Routenanzeige des sekundären CE-Routers über die sekundäre Verbindung des ExpressRoute-Schaltkreises wird wie folgt angezeigt (Junos-Befehle):
user@SEA-MX03-02> show route advertising-protocol bgp 192.168.11.22
Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
Um die hohe Verfügbarkeit der Sicherungsverbindung zu verbessern, wird das S2S-VPN auch im aktiven Modus konfiguriert. Die Konfiguration des Azure VPN-Gateways wird wie folgt angezeigt. Beachten Sie im Rahmen der VPN-Konfiguration auch die BGP-Peer-IP-Adressen des Gateways (10.17.11.76 und 10.17.11.77), die ebenfalls aufgelistet sind.
Die lokale Route wird von der Firewall an die primären und sekundären BGP-Peers des VPN-Gateways angekündigt. Die Routenanzeigen werden wie folgt angezeigt (Junos):
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.76
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
{primary:node0}
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.77
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
Hinweis
Das Konfigurieren des S2S-VPN im aktiv-aktiven Modus bietet nicht nur eine hohe Verfügbarkeit für die Netzwerkkonnektivität Ihres Notfallwiederherstellungs-Backups, sondern auch einen höheren Durchsatz für die Backup-Konnektivität. Daher wird das Konfigurieren von S2S VPN im aktiven Modus empfohlen, da mehrere zugrunde liegende Tunnel erstellt werden.
Konfigurieren des symmetrischen Datenverkehrsflusses
Wir haben festgestellt, dass Azure den ExpressRoute-Pfad bevorzugen würde, wenn eine bestimmte lokale Route sowohl über ExpressRoute als auch über S2S VPN angekündigt wird. Um Azure zu veranlassen, den S2S-VPN-Pfad gegenüber dem koexistierenden ExpressRoute zu bevorzugen, müssen Sie spezifischere Routen (längeres Präfix mit größerer Subnetzmaske) über die VPN-Verbindung bewerben. Unser Ziel ist es, die VPN-Verbindungen nur als Sicherung zu verwenden. Das Standardmäßige Pfadauswahlverhalten von Azure entspricht also unserem Ziel.
Es liegt in unserer Verantwortung sicherzustellen, dass der Datenverkehr, der von der lokalen Umgebung an Azure gesendet wird, auch den ExpressRoute-Pfad dem Standort-zu-Standort-VPN vorzieht. Die lokale Standardeinstellung der CE-Router und Firewalls in unserem lokalen Setup ist 100. Wenn Sie also die lokale Präferenz der Routen konfigurieren, die über die privaten ExpressRoute-Peerings empfangen werden und deren Präferenzwert größer als 100 ist, können wir den Datenverkehr, der für Azure bestimmt ist, den ExpressRoute-Schaltkreis bevorzugen lassen.
Die BGP-Konfiguration des primären CE-Routers, der die primäre Verbindung des ExpressRoute-Schaltkreises beendet, wird wie folgt dargestellt. Beachten Sie den Wert der lokalen Präferenz der über die iBGP-Sitzung angekündigten Routen, die auf 150 konfiguriert ist. Ebenso müssen wir sicherstellen, dass die lokale Präferenz des sekundären CE-Routers, der die sekundäre Verbindung der ExpressRoute-Verbindung endet, ebenfalls auf 150 eingestellt ist.
user@SEA-MX03-01> show configuration routing-instances Cust11
description "Customer 11 VRF";
instance-type virtual-router;
interface xe-0/0/0:0.110;
interface ae0.11;
protocols {
bgp {
group ibgp {
type internal;
local-preference 150;
neighbor 192.168.11.1;
}
group ebgp {
peer-as 12076;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
}
neighbor 192.168.11.18;
}
}
}
Die Routingtabelle der lokalen Firewalls bestätigt, dass für den lokalen Datenverkehr, der für Azure bestimmt ist, der bevorzugte Pfad über ExpressRoute im stabilen Zustand liegt.
user@SEA-SRX42-01> show route table Cust11.inet.0 10.17.11.0/24
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.17.11.0/25 *[BGP/170] 2d 00:34:04, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.0 via reth1.11
to 192.168.11.2 via reth2.11
[BGP/170] 2d 00:34:01, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.2 via reth2.11
[BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
AS path: 65515 I, validation-state: unverified
> via st0.118
[BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
AS path: 65515 I, validation-state: unverified
> via st0.119
10.17.11.76/32 *[Static/5] 2d 21:12:16
> via st0.118
10.17.11.77/32 *[Static/5] 2d 00:41:56
> via st0.119
10.17.11.128/26 *[BGP/170] 2d 00:34:04, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.0 via reth1.11
to 192.168.11.2 via reth2.11
[BGP/170] 2d 00:34:01, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.2 via reth2.11
[BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
AS path: 65515 I, validation-state: unverified
> via st0.118
[BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
AS path: 65515 I, validation-state: unverified
> via st0.119
In der obigen Routentabelle sehen wir, dass für die Routen des Hub- und Spoke-Virtualnetzwerks--10.17.11.0/25 und 10.17.11.128/26--der ExpressRoute-Kreislauf gegenüber VPN-Verbindungen bevorzugt wird. Die 192.168.11.0 und 192.168.11.2 sind IPs auf der Firewallschnittstelle gegenüber CE-Routern.
Überprüfung des Routingaustauschs über S2S VPN
Weiter oben in diesem Artikel haben wir die lokale Routenankündigung der Firewalls für den primären und den sekundären BGP-Peer des VPN-Gateways überprüft. Lassen Sie uns außerdem die von den Firewalls empfangenen Azure-Routen von den primären und sekundären BGP-Peers des VPN-Gateways bestätigen.
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.76 table Cust11.inet.0
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
10.17.11.0/25 10.17.11.76 65515 I
10.17.11.128/26 10.17.11.76 65515 I
{primary:node0}
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.77 table Cust11.inet.0
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
10.17.11.0/25 10.17.11.77 65515 I
10.17.11.128/26 10.17.11.77 65515 I
Ebenso überprüfen wir, ob lokale Netzwerkroutenpräfixe vom Azure-VPN-Gateway empfangen werden.
PS C:\Users\user> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | where {$_.Network -eq "10.1.11.0/25"} | select Network, NextHop, AsPath, Weight
Network NextHop AsPath Weight
------- ------- ------ ------
10.1.11.0/25 192.168.11.88 65020 32768
10.1.11.0/25 10.17.11.76 65020 32768
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 192.168.11.88 65020 32768
10.1.11.0/25 10.17.11.77 65020 32768
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 10.17.11.69 12076-65020 32769
Wie bereits erwähnt, verfügt das VPN-Gateway über Routen, die sowohl von den primären als auch von sekundären BGP-Peers des VPN-Gateways empfangen werden. Außerdem sind die über primäre und sekundäre ExpressRoute-Verbindungen empfangenen Routen (bei denen „AsPath“ der Wert „12076“ vorangestellt ist) sichtbar. Um die über VPN-Verbindungen empfangenen Routen zu bestätigen, müssen wir die lokale BGP-Peer-IP der Verbindungen kennen. In unserem betrachteten Setup ist die IP 192.168.11.88, und wir sehen die von ihr empfangenen Routen.
Als Nächstes überprüfen wir die vom Azure VPN-Gateway angekündigten Routen an den BGP-Peer der lokalen Firewall (192.168.11.88).
PS C:\Users\user> Get-AzVirtualNetworkGatewayAdvertisedRoute -Peer 192.168.11.88 -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | select Network, NextHop, AsPath, Weight
Network NextHop AsPath Weight
------- ------- ------ ------
10.17.11.0/25 10.17.11.76 65515 0
10.17.11.128/26 10.17.11.76 65515 0
10.17.11.0/25 10.17.11.77 65515 0
10.17.11.128/26 10.17.11.77 65515 0
Wenn der Routenaustausch nicht angezeigt wird, weist dies auf einen Verbindungsfehler hin. Siehe Problembehandlung: Eine Vpn-Verbindung mit azure site-to-site kann keine Verbindung herstellen und funktioniert nicht mehr, um Hilfe bei der Problembehandlung bei der VPN-Verbindung zu erhalten.
Testen des Failovers
Nachdem wir nun den erfolgreichen Routenaustausch über die VPN-Verbindung (Kontrollebene) bestätigt haben, sind wir so eingestellt, dass der Datenverkehr (Datenebene) von der ExpressRoute-Konnektivität zur VPN-Konnektivität gewechselt wird.
Hinweis
Failovertests in Produktionsumgebungen müssen während des geplanten Arbeitsfensters für die Netzwerkwartung durchgeführt werden, da es zu Unterbrechungen des Diensts kommen kann.
Vor der Umstellung des Datenverkehrs verfolgen wir die Route des aktuellen Pfads in unserem Setup vom lokalen Testserver zur Test-VM im Spoke-VNet.
C:\Users\PathLabUser>tracert 10.17.11.132
Tracing route to 10.17.11.132 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.1.11.1
2 <1 ms <1 ms 11 ms 192.168.11.0
3 <1 ms <1 ms <1 ms 192.168.11.18
4 * * * Request timed out.
5 6 ms 6 ms 5 ms 10.17.11.132
Trace complete.
Die primären und sekundären ExpressRoute-Point-to-Point-Verbindungssubnetze unserer Einrichtung sind jeweils 192.168.11.16/30 und 192.168.11.20/30. In Schritt 3 der obigen Ablaufverfolgungsroute sehen wir, dass wir auf 192.168.11.18 treffen, was die Schnittstellen-IP des primären MSEE ist. Das Vorhandensein der MSEE-Schnittstelle bestätigt, dass unser aktueller Pfad über expressRoute liegt, wie erwartet.
Wie im Artikel Zurücksetzen von ExpressRoute-Verbindungspeerings beschrieben, verwenden wir die folgenden PowerShell-Befehle, um das primäre und das sekundäre Peering der ExpressRoute-Verbindung zu deaktivieren.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Die Failoverschalterzeit hängt von der BGP-Konvergenzzeit ab. In unserer Konfiguration dauert die Failover-Umschaltung ein paar Sekunden (weniger als 10). Nach der Umstellung wird beim Wiederholen der Routenverfolgung der folgende Pfad angezeigt:
C:\Users\PathLabUser>tracert 10.17.11.132
Tracing route to 10.17.11.132 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.1.11.1
2 * * * Request timed out.
3 6 ms 7 ms 9 ms 10.17.11.132
Trace complete.
Das Traceroute-Ergebnis bestätigt, dass die Sicherungsverbindung über S2S VPN aktiv ist und dienstkontinuität bereitstellen kann, wenn sowohl die primären als auch die sekundären ExpressRoute-Verbindungen fehlschlagen. Um die Failovertests abzuschließen, aktivieren wir die ExpressRoute-Verbindungen zurück und normalisieren den Datenverkehrsfluss mithilfe der folgenden Befehlssätze.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Um zu bestätigen, dass der Datenverkehr wieder auf ExpressRoute umgestellt wird, wiederholen Sie die Routenverfolgung, und stellen Sie sicher, dass die private ExpressRoute-Peeringverbindung verwendet wird.
Nächste Schritte
ExpressRoute ist für hohe Verfügbarkeit ohne einzelnen Fehlerpunkt innerhalb des Microsoft-Netzwerks konzipiert. Dennoch ist ein ExpressRoute-Schaltkreis auf eine einzelne geografische Region und auf einen Dienstanbieter beschränkt. S2S VPN kann eine gute passive Notfallwiederherstellungslösung für eine ExpressRoute-Leitung sein. Für eine zuverlässige passive Sicherungsverbindungslösung sind regelmäßige Wartung der passiven Konfiguration und regelmäßige Überprüfung der Verbindung wichtig. Es ist wichtig, nicht zuzulassen, dass die VPN-Konfiguration veraltet wird, und in regelmäßigen Abständen (z. B. jedes Quartal) die in diesem Artikel beschriebenen Überprüfungs- und Failovertestschritte während des Wartungsfensters wiederholen.
Informationen zum Aktivieren von Überwachung und Warnungen basierend auf VPN-Gatewaymetriken finden Sie unter Einrichten von Warnungen zu VPN-Gatewaymetriken.
Um die BGP-Konvergenz nach einem ExpressRoute-Fehler zu beschleunigen, konfigurieren Sie BFD über ExpressRoute.