S2S VPN gebruiken als back-up voor persoonlijke ExpressRoute-peering
In het artikel ontwerpen voor herstel na noodgevallen met persoonlijke ExpressRoute-peering hebben we de noodzaak besproken van een back-upverbindingsoplossing bij het gebruik van persoonlijke ExpressRoute-peering. We hebben ook besproken hoe u geografisch redundante ExpressRoute-circuits gebruikt voor hoge beschikbaarheid. In dit artikel wordt uitgelegd hoe u een site-naar-site-VPN (S2S) gebruikt en onderhoudt als back-up voor persoonlijke ExpressRoute-peering.
Notitie
Het gebruik van site-naar-site-VPN als back-upoplossing voor ExpressRoute-connectiviteit wordt niet aanbevolen bij latentiegevoelige, bedrijfskritieke of bandbreedte-intensieve workloads. In dergelijke gevallen is het raadzaam om te ontwerpen voor herstel na noodgevallen met ExpressRoute-tolerantie voor meerdere locaties om maximale beschikbaarheid te garanderen.
In tegenstelling tot geografisch redundante ExpressRoute-circuits kunt u alleen expressRoute- en VPN-herstel na noodgevallen gebruiken in een actief-passieve installatie. Een grote uitdaging bij het gebruik van back-upnetwerkconnectiviteit in de passieve modus is dat de passieve verbinding vaak mislukt naast de primaire verbinding. De veelvoorkomende reden voor de storingen van de passieve verbinding is een gebrek aan actief onderhoud. Daarom is in dit artikel de focus op het controleren en actief onderhouden van een S2S VPN-verbinding die een back-up maakt van een Persoonlijke ExpressRoute-peering.
Notitie
Wanneer een bepaalde route wordt geadverteerd via zowel ExpressRoute als VPN, geeft Azure de voorkeur aan routering via ExpressRoute.
In dit artikel leert u ook hoe u de connectiviteit controleert vanuit zowel het perspectief van Azure als de randzijde van het on-premises netwerk. De mogelijkheid om van beide kanten te valideren, helpt ongeacht of u de on-premises netwerkapparaten beheert die peeren met de Microsoft-netwerkentiteiten.
Voorbeeldtopologie
In onze installatie hebben we een on-premises netwerk dat is verbonden met een virtueel Azure Hub-netwerk via zowel een ExpressRoute-circuit als een S2S VPN-verbinding. Het virtuele Azure Hub-netwerk is op zijn beurt gekoppeld aan een virtueel spoke-netwerk, zoals wordt weergegeven in het diagram:
In de installatie wordt het ExpressRoute-circuit beëindigd op een paar CE-routers (customer edge) op de on-premises locatie. Het on-premises LAN is verbonden met de CE-routers met een paar firewalls die werken in de modus leidervolger. De S2S VPN wordt rechtstreeks beëindigd op de firewalls.
De volgende tabel bevat de belangrijkste IP-voorvoegsels van de topologie:
| Entiteit | Voorvoegsel |
|---|---|
| On-premises LAN | 10.1.11.0/25 |
| Virtueel Azure Hub-netwerk | 10.17.11.0/25 |
| Virtueel Azure Spoke-netwerk | 10.17.11.128/26 |
| On-premises testserver | 10.1.11.10 |
| Virtuele spoke-netwerktest-VM | 10.17.11.132 |
| Primaire ExpressRoute-verbinding P2P-subnet | 192.168.11.16/30 |
| SecundairE ExpressRoute-verbinding P2P-subnet | 192.168.11.20/30 |
| PRIMAIRE BGP-peer-IP van VPN-gateway | 10.17.11.76 |
| SECUNDAIRE BGP-peer-IP van VPN-gateway | 10.17.11.77 |
| IP van on-premises firewall-VPN BGP-peer | 192.168.11.88 |
| Primaire CE-router i/f naar ip-adres van firewall | 192.168.11.0/31 |
| Firewall i/f naar het IP-adres van de primaire CE-router | 192.168.11.1/31 |
| Secundaire CE-router i/f naar firewall-IP | 192.168.11.2/31 |
| Firewall i/f naar secundair CE-router-IP | 192.168.11.3/31 |
De volgende tabel bevat de ASN's van de topologie:
| Autonoom systeem | ASN |
|---|---|
| On-premises | 65020 |
| Microsoft Enterprise Edge | 12076 |
| Virtual Network GW (ExR) | 65515 |
| Virtual Network GW (VPN) | 65515 |
Hoge beschikbaarheid zonder asymmetrischheid
Configureren voor hoge beschikbaarheid
In het artikel ExpressRoute- en site-naar-site-verbindingen configureren wordt uitgelegd hoe u naast elkaar bestaande ExpressRoute- en S2S VPN-verbindingen instelt. Zoals we hebben vermeld in Ontwerpen voor hoge beschikbaarheid met ExpressRoute, zorgt onze installatie ervoor dat netwerkredundantie een single point of failure voor de eindpunten elimineert, waardoor de hoge beschikbaarheid van ExpressRoute wordt verbeterd. Bovendien zijn zowel de primaire als de secundaire verbindingen van de ExpressRoute-circuits actief en adverteren ze de on-premises voorvoegsels op dezelfde manier via beide verbindingen.
De on-premises routeaankoping van de primaire CE-router via de primaire verbinding van het ExpressRoute-circuit wordt als volgt weergegeven (Junos-opdrachten):
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
De on-premises routeaanroep van de secundaire CE-router via de secundaire verbinding van het ExpressRoute-circuit wordt als volgt weergegeven (Junos-opdrachten):
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
Om de hoge beschikbaarheid van de back-upverbinding te verbeteren, wordt de S2S VPN ook geconfigureerd in de modus actief-actief. De configuratie van de Azure VPN-gateway wordt als volgt weergegeven. Let op als onderdeel van de VPN-configuratie-VPN de BGP-peer-IP-adressen van de gateway--10.17.11.76 en 10.17.11.77--worden ook vermeld.
De on-premises route wordt geadverteerd door de firewall naar de primaire en secundaire BGP-peers van de VPN-gateway. De routeadvertenties worden als volgt weergegeven (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
Notitie
Het configureren van de S2S VPN in de actief-actief-modus biedt niet alleen hoge beschikbaarheid voor de back-upnetwerkconnectiviteit voor herstel na noodgevallen, maar biedt ook een hogere doorvoer voor de back-upconnectiviteit. Daarom wordt het configureren van S2S VPN in de actief-actieve modus aanbevolen, omdat er meerdere onderliggende tunnels worden gemaakt.
Configureren voor symmetrische verkeersstroom
We hebben opgemerkt dat wanneer een bepaalde on-premises route wordt geadverteerd via zowel ExpressRoute als S2S VPN, Azure de voorkeur geeft aan het ExpressRoute-pad. Als u wilt afdwingen dat Azure de voorkeur geeft aan het S2S VPN-pad via de naast elkaar bestaande ExpressRoute, moet u specifiekere routes (langer voorvoegsel met een groter subnetmasker) adverteren via de VPN-verbinding. Ons doel is om de VPN-verbindingen alleen als back-up te gebruiken. Het standaardgedrag voor padselectie van Azure is dus in overeenstemming met ons doel.
Het is onze verantwoordelijkheid om ervoor te zorgen dat het verkeer dat is bestemd voor Azure vanaf on-premises, ook de voorkeur geeft aan expressRoute-pad via de site-naar-site-VPN. De standaard lokale voorkeur van de CE-routers en firewalls in onze on-premises installatie is 100. Door dus de lokale voorkeur te configureren van de routes die worden ontvangen via de expressRoute-privépeeringen die groter zijn dan 100, kunnen we het verkeer dat is bestemd voor Azure, de voorkeur geven aan het ExpressRoute-circuit.
De BGP-configuratie van de primaire CE-router die de primaire verbinding van het ExpressRoute-circuit beëindigt, wordt als volgt weergegeven. Let op de waarde van de lokale voorkeur van de routes die worden geadverteerd via de iBGP-sessie is geconfigureerd op 150. Op dezelfde manier moeten we ervoor zorgen dat de lokale voorkeur van de secundaire CE-router die de secundaire verbinding van het ExpressRoute-circuit beëindigt, ook is geconfigureerd als 150.
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;
}
}
}
De routeringstabel van de on-premises firewalls bevestigt dat voor het on-premises verkeer dat is bestemd voor Azure het voorkeurspad zich via ExpressRoute in de stabiele toestand bevindt.
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 de bovenstaande routetabel, voor de hub- en spoke virtuele netwerkroutes---10.17.11.0/25 en 10.17.11.128/26--zien we dat het ExpressRoute-circuit de voorkeur heeft boven VPN-verbindingen. De 192.168.11.0 en 192.168.11.2 zijn IP-adressen op de firewallinterface naar CE-routers.
Validatie van routeringsuitwisseling via S2S VPN
Eerder in dit artikel hebben we on-premises routeadvertentie van de firewalls gecontroleerd op de primaire en secundaire BGP-peers van de VPN-gateway. Daarnaast gaan we controleren of Azure-routes die zijn ontvangen door de firewalls van de primaire en secundaire BGP-peers van de VPN-gateway, worden bevestigd.
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
Laten we ook controleren op on-premises netwerkroutevoorvoegsels die zijn ontvangen door de Azure VPN-gateway.
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
Zoals eerder gezien, heeft de VPN-gateway routes ontvangen door de primaire en secundaire BGP-peers van de VPN-gateway. Het heeft ook zicht op de routes die worden ontvangen via primaire en secundaire ExpressRoute-verbindingen (de routes met AS-pad voorafgegaan door 12076). Om te bevestigen dat de routes die via VPN-verbindingen worden ontvangen, moeten we het on-premises IP-adres van de BGP-peer van de verbindingen kennen. In onze instelling die wordt overwogen, is het IP-adres 192.168.11.88 en zien we de routes die ermee zijn ontvangen.
Vervolgens gaan we controleren of de routes die door de Azure VPN-gateway worden geadverteerd naar de BGP-peer van de on-premises 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
Fout bij het zien van route-uitwisselingen geven aan dat er een verbindingsfout is opgetreden. Zie Probleemoplossing: Een Azure-site-naar-site-VPN-verbinding kan geen verbinding maken en werkt niet meer voor hulp bij het oplossen van problemen met de VPN-verbinding.
Failover testen
Nu we hebben bevestigd dat de uitwisseling van routes via de VPN-verbinding (besturingsvlak) is geslaagd, zijn we ingesteld om verkeer (gegevensvlak) van de ExpressRoute-verbinding met de VPN-connectiviteit te schakelen.
Notitie
In productieomgevingen moeten failovertests worden uitgevoerd tijdens het geplande werkvenster voor netwerkonderhoud, omdat dit de service verstorend kan zijn.
Voordat u de verkeersswitch uitvoert, volgen we het huidige pad in de installatie van de on-premises testserver naar de test-VM in het virtuele spoke-netwerk.
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.
De primaire en secundaire ExpressRoute-punt-naar-punt-subnetten van onze installatie zijn respectievelijk 192.168.11.16/30 en 192.168.11.20/30. In de bovenstaande traceringsroute zien we in stap 3 dat we 192.168.11.18 bereiken. Dit is het interface-IP-adres van de primaire MSEE. Aanwezigheid van de MSEE-interface bevestigt dat ons huidige pad naar verwachting via de ExpressRoute verloopt.
Zoals gerapporteerd in peerings van expressRoute-circuits opnieuw instellen, gebruiken we de volgende PowerShell-opdrachten om zowel de primaire als de secundaire peering van het ExpressRoute-circuit uit te schakelen.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
De tijd van de failoverswitch is afhankelijk van de BGP-convergentietijd. In onze installatie duurt de failover-switch een paar seconden (minder dan 10). Na de switch wordt het volgende pad weergegeven door de traceroute te herhalen:
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.
Het traceroute-resultaat bevestigt dat de back-upverbinding via S2S VPN actief is en kan servicecontinuïteit bieden als zowel de primaire als de secundaire ExpressRoute-verbindingen mislukken. Als u de failovertests wilt voltooien, schakelt u de ExpressRoute-verbindingen terug en normaliseert u de verkeersstroom met behulp van de volgende set opdrachten.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Herhaal de traceringsroute om te bevestigen dat het verkeer wordt teruggeschakeld naar ExpressRoute en zorg ervoor dat het via de persoonlijke ExpressRoute-peering gaat.
Volgende stappen
ExpressRoute is ontworpen voor hoge beschikbaarheid zonder single point of failure binnen het Microsoft-netwerk. Nog steeds is een ExpressRoute-circuit beperkt tot één geografische regio en een serviceprovider. S2S VPN kan een goede passieve back-upoplossing voor herstel na noodgevallen naar een ExpressRoute-circuit zijn. Voor een betrouwbare passieve back-upverbindingsoplossing is het regelmatig onderhoud van de passieve configuratie en periodieke validatie van de verbinding belangrijk. Het is essentieel om de VPN-configuratie niet te laten verlopen en om periodiek (bijvoorbeeld elk kwartaal) de validatie- en failoverteststappen te herhalen die in dit artikel tijdens het onderhoudsvenster worden beschreven.
Zie Waarschuwingen instellen voor metrische gegevens van VPN Gateway om bewaking en waarschuwingen in te schakelen op basis van metrische gegevens van VPN Gateway.
Configureer BFD via ExpressRoute om BGP-convergentie te versnellen na een ExpressRoute-fout.