Uso della VPN S2S come backup per il peering privato di ExpressRouteUsing S2S VPN as a backup for ExpressRoute private peering

Nell'articolo intitolato progettazione per il ripristino di emergenza con peering privato ExpressRoute, è stata discussa la necessità di una soluzione di connettività di backup per una connettività di peering privato ExpressRoute e come usare circuiti ExpressRoute con ridondanza geografica per lo scopo.In the article titled Designing for disaster recovery with ExpressRoute private peering, we discussed the need for backup connectivity solution for an ExpressRoute private peering connectivity and how to use geo-redundant ExpressRoute circuits for the purpose. Questo articolo illustra come usare e gestire la VPN da sito a sito (S2S) come backup per il peering privato ExpressRoute.In this article, let us consider how to leverage and maintain site-to-site (S2S) VPN as a backup for ExpressRoute private peering.

A differenza dei circuiti ExpressRoute con ridondanza geografica, è possibile usare la combinazione di ripristino di emergenza ExpressRoute-VPN solo in modalità attivo/passivo.Unlike geo-redundant ExpressRoute circuits, you can use ExpressRoute-VPN disaster recovery combination only in active-passive mode. Un problema principale dell'utilizzo della connettività di rete di backup in modalità passiva è che la connessione passiva avrebbe spesso esito negativo insieme alla connessione primaria.A major challenge of using any backup network connectivity in the passive mode is that the passive connection would often fail alongside the primary connection. La causa comune degli errori della connessione passiva è la mancanza di manutenzione attiva.The common reason for the failures of the passive connection is lack of active maintenance. Pertanto, in questo articolo si concentrerà su come verificare e mantenere attivamente la connettività VPN S2S che esegue il backup di un peering privato ExpressRoute.Therefore, in this article let's focus on how to verify and actively maintain S2S VPN connectivity that is backing up an ExpressRoute private peering.

Nota

Quando una determinata route viene annunciata tramite ExpressRoute e VPN, Azure preferisce il routing rispetto a ExpressRoute.When a given route is advertised via both ExpressRoute and VPN, Azure would prefer routing over ExpressRoute.

In questo articolo viene illustrato come verificare la connettività sia dal punto di vista di Azure che dal punto di vista del perimetro della rete lato client.In this article, let's see how to verify the connectivity both from the Azure perspective and the customer side network edge perspective. La possibilità di convalidare da entrambe le estremità può essere utile indipendentemente dal fatto che i dispositivi di rete lato cliente vengano gestiti da peer con le entità di rete Microsoft.Ability to validate from either end will help irrespective of whether or not you manage the customer side network devices that peer with the Microsoft network entities.

Topologia di esempioExample topology

Nel programma di installazione è presente una rete locale connessa a un VNet Hub di Azure tramite un circuito ExpressRoute e una connessione VPN S2S.In our setup, we have an on-premises network connected to an Azure hub VNet via both an ExpressRoute circuit and a S2S VPN connection. Il VNet dell'hub di Azure viene a sua volta sottoposta a peering in un VNet spoke, come illustrato nel diagramma seguente:The Azure hub VNet is in turn peered to a spoke VNet, as shown in the diagram below:

11

Nel programma di installazione, il circuito ExpressRoute viene terminato in una coppia di router "Customer Edge" (CE) in locale.In the setup, the ExpressRoute circuit is terminated on a pair of "Customer Edge" (CE) routers at the on-premises. La LAN locale è connessa ai router CE tramite una coppia di firewall che operano in modalità di guida.The on-premises LAN is connected to the CE routers via a pair of firewalls that operate in leader-follower mode. La VPN S2S viene terminata direttamente nei firewall.The S2S VPN is directly terminated on the firewalls.

Nella tabella seguente sono elencati i prefissi IP principali della topologia:The following table lists the key IP prefixes of the topology:

EntitàEntity PrefixPrefix
LAN localeOn-premises LAN 10.1.11.0/2510.1.11.0/25
VNet Hub di AzureAzure Hub VNet 10.17.11.0/2510.17.11.0/25
Azure spoke VNetAzure spoke VNet 10.17.11.128/2610.17.11.128/26
Server di prova localeOn-premises test server 10.1.11.1010.1.11.10
VM di test VNet spokeSpoke VNet test VM 10.17.11.13210.17.11.132
ExpressRoute subnet P2P della connessione primariaExpressRoute primary connection p2p subnet 192.168.11.16/30192.168.11.16/30
Subnet P2P della connessione secondaria ExpressRouteExpressRoute secondary connection p2p subnet 192.168.11.20/30192.168.11.20/30
IP peer BGP primario del gateway VPNVPN gateway primary BGP peer IP 10.17.11.7610.17.11.76
IP del peer BGP secondario del gateway VPNVPN gateway secondary BGP peer IP 10.17.11.7710.17.11.77
IP peer BGP VPN firewall localeOn-premises firewall VPN BGP peer IP 192.168.11.88192.168.11.88
I/o del router CE primario per l'IP del firewallPrimary CE router i/f towards firewall IP 192.168.11.0/31192.168.11.0/31
I/o del firewall verso l'indirizzo IP del router CE primarioFirewall i/f towards primary CE router IP 192.168.11.1/31192.168.11.1/31
I/o del router CE secondario per l'IP del firewallSecondary CE router i/f towards firewall IP 192.168.11.2/31192.168.11.2/31
I/o del firewall verso l'IP del router CE secondarioFirewall i/f towards secondary CE router IP 192.168.11.3/31192.168.11.3/31

Nella tabella seguente sono elencati i ASN della topologia:The following table lists the ASNs of the topology:

Sistema autonomoAutonomous system ASNASN
LocaleOn-premises 6502065020
Microsoft Enterprise EdgeMicrosoft Enterprise Edge 1207612076
Rete virtuale GW (ExR)Virtual Network GW (ExR) 6551565515
Rete virtuale GW (VPN)Virtual Network GW (VPN) 6551565515

Disponibilità elevata senza asimmetriaHigh availability without asymmetricity

Configurazione per la disponibilità elevataConfiguring for high availability

Configurare connessioni coesistenti ExpressRoute e da sito a sito illustra come configurare il circuito ExpressRoute coesistente e le connessioni VPN S2S.Configure ExpressRoute and Site-to-Site coexisting connections discusses how to configure the coexisting ExpressRoute circuit and S2S VPN connections. Come illustrato in progettazione per la disponibilità elevata con ExpressRoute, per migliorare la disponibilità elevata di ExpressRoute la configurazione mantiene la ridondanza della rete (evita il singolo punto di errore) fino agli endpoint.As we discussed in Designing for high availability with ExpressRoute, to improve ExpressRoute high availability our setup maintains the network redundancy (avoids single point of failure) all the way up to the endpoints. Inoltre, le connessioni primarie e secondarie dei circuiti ExpressRoute sono configurate per essere eseguite in modalità attivo-attivo mediante l'annuncio dei prefissi locali nello stesso modo tramite entrambe le connessioni.Also both the primary and secondary connections of the ExpressRoute circuits are configured to operate in active-active mode by advertising the on-premises prefixes the same way through both the connections.

L'annuncio della route locale del router CE primario attraverso la connessione primaria del circuito ExpressRoute è illustrato di seguito (comandi Junos):The on-premises route advertisement of the primary CE router through the primary connection of the ExpressRoute circuit is show below (Junos commands):

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

L'annuncio della route locale del router CE secondario tramite la connessione secondaria del circuito ExpressRoute è illustrato di seguito (comandi di Junos):The on-premises route advertisement of the secondary CE router through the secondary connection of the ExpressRoute circuit is show below (Junos commands):

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

Per migliorare la disponibilità elevata della connessione di backup, la VPN S2S viene configurata anche in modalità attivo-attivo.To improve the high availability of the backup connection, the S2S VPN is also configured in the active-active mode. La configurazione del gateway VPN di Azure è illustrata di seguito.The Azure VPN gateway configuration is shown below. Nota come parte della VPN di configurazione VPN, sono elencati anche gli indirizzi IP del peer BGP del gateway, 10.17.11.76 e 10.17.11.77.Note as part of the VPN configuration VPN the BGP peer IP addresses of the gateway--10.17.11.76 and 10.17.11.77--are also listed.

22

La route locale viene annunciata dai firewall ai peer BGP primari e secondari del gateway VPN.The on-premises route is advertised by the firewalls to the primary and secondary BGP peers of the VPN gateway. Gli annunci di route sono riportati di seguito (Junos):The route advertisements are shown below (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

Nota

La configurazione della VPN S2S in modalità Active-Active non solo garantisce la disponibilità elevata per la connettività di rete per il ripristino di emergenza, ma offre anche una velocità effettiva superiore per la connettività di backup.Configuring the S2S VPN in active-active mode not only provides high-availability to your disaster recovery backup network connectivity, but also provides higher throughput to the backup connectivity. In altre parole, è consigliabile configurare la VPN S2S in modalità Active-Active, perché forza la creazione di più tunnel sottostanti.In other words, configuring S2S VPN in active-active mode is recommended as it force create multiple underlying tunnels.

Configurazione per il flusso del traffico simmetricoConfiguring for symmetric traffic flow

Si noti che quando una determinata route locale viene annunciata tramite la VPN ExpressRoute e S2S, Azure preferisce il percorso ExpressRoute.We noted that when a given on-premises route is advertised via both ExpressRoute and S2S VPN, Azure would prefer the ExpressRoute path. Per fare in modo che Azure preferisca il percorso VPN S2S sulla ExpressRoute coesistente, è necessario annunciare route più specifiche (prefisso più lungo con subnet mask più grandi) tramite la connessione VPN.To force Azure prefer S2S VPN path over the coexisting ExpressRoute, you need to advertise more specific routes (longer prefix with bigger subnet mask) via the VPN connection. Il nostro obiettivo consiste nell'usare le connessioni VPN solo come backup.Our objective here is to use the VPN connections as backup only. Il comportamento predefinito per la selezione dei percorsi di Azure è quindi in linea con l'obiettivo.So, the default path selection behavior of Azure is in-line with our objective.

È responsabilità del garante che il traffico destinato ad Azure da locale preferisca anche il percorso ExpressRoute sulla VPN S2S.It is our responsibility to ensure that the traffic destined to Azure from on-premises also prefers ExpressRoute path over S2S VPN. La preferenza locale predefinita dei router CE e dei firewall nell'installazione locale è 100.The default local preference of the CE routers and firewalls in our on-premises setup is 100. Quindi, configurando la preferenza locale delle route ricevute tramite i peering privati di ExpressRoute maggiori di 100 (ad indicare 150), è possibile fare in modo che il traffico destinato ad Azure preferisca il circuito ExpressRoute nello stato stazionario.So, by configuring the local preference of the routes received through the ExpressRoute private peerings greater than 100 (say 150), we can make the traffic destined to Azure prefer ExpressRoute circuit in the steady state.

Di seguito è riportata la configurazione BGP del router CE primario che termina la connessione primaria del circuito ExpressRoute.The BGP configuration of the primary CE router that terminates the primary connection of the ExpressRoute circuit is shown below. Si noti che il valore della preferenza locale delle route annunciate sulla sessione iBGP è configurato per essere 150.Note the value of the local preference of the routes advertised over the iBGP session is configured to be 150. Analogamente, è necessario assicurarsi che la preferenza locale del router CE secondario che termina la connessione secondaria del circuito ExpressRoute sia configurata anche come 150.Similarly, we need to ensure the local preference of the secondary CE router that terminates the secondary connection of the ExpressRoute circuit is also configured to be 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;
    }
  }
}

La tabella di routing dei firewall locali conferma (mostrata di seguito) che per il traffico locale destinato ad Azure il percorso preferito è rispetto a ExpressRoute nello stato stazionario.The routing table of the on-premises firewalls confirms (shown below) that for the on-premises traffic that is destined to Azure the preferred path is over ExpressRoute in the steady state.

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

Nella tabella di route precedente, per l'hub e spoke VNet Routes--10.17.11.0/25 e 10.17.11.128/26. viene visualizzato il circuito ExpressRoute preferito rispetto alle connessioni VPN.In the above route table, for the hub and spoke VNet routes--10.17.11.0/25 and 10.17.11.128/26--we see ExpressRoute circuit is preferred over VPN connections. 192.168.11.0 e 192.168.11.2 sono indirizzi IP sull'interfaccia firewall per i router CE.The 192.168.11.0 and 192.168.11.2 are IPs on firewall interface towards CE routers.

Convalida dello scambio delle route tramite VPN S2SValidation of route exchange over S2S VPN

In precedenza in questo articolo è stata verificata l'annuncio delle route locali dei firewall per i peer BGP primari e secondari del gateway VPN.Earlier in this article, we verified on-premises route advertisement of the firewalls to the primary and secondary BGP peers of the VPN gateway. Inoltre, è necessario confermare le route di Azure ricevute dai firewall dai peer BGP primari e secondari del gateway VPN.Additionally, let's confirm Azure routes received by the firewalls from the primary and secondary BGP peers of the VPN gateway.

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

Analogamente, si verificheranno i prefissi di route di rete locali ricevuti dal gateway VPN di Azure.Similarly let's verify for on-premises network route prefixes received by the 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

Come illustrato in precedenza, il gateway VPN contiene route ricevute dal peer BGP primario e secondario del gateway VPN.As seen above, the VPN gateway has routes received both by the primary and secondary BGP peers of the VPN gateway. Ha anche visibilità sulle route ricevute tramite le connessioni ExpressRoute primarie e secondarie (quelle con il percorso come anteposto a 12076).It also has visibility over the routes received via primary and secondary ExpressRoute connections (the ones with AS-path prepended with 12076). Per confermare le route ricevute tramite connessioni VPN, è necessario che l'indirizzo IP del peer BGP locale delle connessioni sia noto.To confirm the routes received via VPN connections, we need to know the on-premises BGP peer IP of the connections. Nel corso della configurazione, in considerazione, è 192.168.11.88 e vengono visualizzate le route ricevute.In our setup under consideration, it is 192.168.11.88 and we do see the routes received from it.

Successivamente, è possibile verificare le route annunciate dal gateway VPN di Azure al peer BGP del firewall locale (192.168.11.88).Next, let's verify the routes advertised by the Azure VPN gateway to the on-premises firewall BGP peer (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

La mancata visualizzazione degli scambi di route indica un errore di connessione.Failure to see route exchanges indicate connection failure. Vedere risoluzione dei problemi: una connessione VPN da sito a sito di Azure non può connettersi e smette di funzionare per informazioni sulla risoluzione dei problemi relativi alla connessione VPN.See Troubleshooting: An Azure site-to-site VPN connection cannot connect and stops working for help with troubleshooting the VPN connection.

Test del failoverTesting failover

Ora che sono stati confermati gli scambi di route riusciti sulla connessione VPN (piano di controllo), viene impostato il passaggio del traffico (piano dati) dalla connettività ExpressRoute alla connettività VPN.Now that we have confirmed successful route exchanges over the VPN connection (control plane), we are set to switch traffic (data plane) from the ExpressRoute connectivity to the VPN connectivity.

Nota

Negli ambienti di produzione il test di failover deve essere eseguito durante la manutenzione pianificata della rete-finestra di lavoro, perché può essere un disturbo del servizio.In production environments failover testing has to be done during scheduled network maintenance work-window as it can be service disruptive.

Prima di eseguire il cambio di traffico, è possibile tracciare il percorso corrente dell'installazione dal server di prova locale alla VM di test nel VNet spoke.Prior to do the traffic switch, let's trace route the current path in our setup from the on-premises test server to the test VM in the 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.

Le subnet di connessione Point-to-Point ExpressRoute primaria e secondaria della configurazione sono rispettivamente 192.168.11.16/30 e 192.168.11.20/30.The primary and secondary ExpressRoute point-to-point connection subnets of our setup are, respectively, 192.168.11.16/30 and 192.168.11.20/30. Nella route di traccia precedente, nel passaggio 3 si noterà che si sta colpendo 192.168.11.18, che è l'indirizzo IP dell'interfaccia del MSEE primario.In the above trace route, in step 3 we see that we are hitting 192.168.11.18, which is the interface IP of the primary MSEE. La presenza dell'interfaccia MSEE conferma che, come previsto, il percorso corrente è sopra il ExpressRoute.Presence of MSEE interface confirms that as expected our current path is over the ExpressRoute.

Come indicato nei peering del circuito ExpressRoute Reset, usare i comandi di PowerShell seguenti per disabilitare il peering primario e secondario del circuito ExpressRoute.As reported in the Reset ExpressRoute circuit peerings, let's use the following powershell commands to disable both the primary and secondary peering of the ExpressRoute circuit.

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

Il tempo di commutazione del failover dipende dal tempo di convergenza BGP.The failover switch time depends on the BGP convergence time. Nel programma di installazione, l'opzione di failover richiede pochi secondi (minore di 10).In our setup, the failover switch takes a few seconds (less than 10). Dopo l'opzione, la ripetizione del traceroute mostra il percorso seguente:After the switch, repeat of the traceroute shows the following path:

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.

Il risultato del traceroute conferma che la connessione di backup tramite la VPN S2S è attiva e può garantire la continuità del servizio se le connessioni ExpressRoute primarie e secondarie hanno esito negativo.The traceroute result confirms that the backup connection via S2S VPN is active and can provide service continuity if both the primary and secondary ExpressRoute connections fail. Per completare il test di failover, abilitare le connessioni ExpressRoute e normalizzare il flusso del traffico, usando il set di comandi seguente.To complete the failover testing, let's enable the ExpressRoute connections back and normalize the traffic flow, using the following set of commands.

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

Per confermare che il traffico viene reimpostato su ExpressRoute, ripetere il traceroute e verificare che venga eseguito il peering privato di ExpressRoute.To confirm the traffic is switched back to ExpressRoute, repeat the traceroute and ensure that it is going through the ExpressRoute private peering.

Passaggi successiviNext steps

ExpressRoute è progettato per la disponibilità elevata senza un singolo punto di errore all'interno della rete Microsoft.ExpressRoute is designed for high availability with no single point of failure within the Microsoft network. Un circuito ExpressRoute è comunque limitato a una singola area geografica e a un provider di servizi.Still an ExpressRoute circuit is confined to a single geographical region and to a service provider. La VPN S2S può essere una soluzione di backup passivo per il ripristino di emergenza in un circuito ExpressRoute.S2S VPN can be a good disaster recovery passive backup solution to an ExpressRoute circuit. Per una soluzione di connessione di backup passiva affidabile, è importante la manutenzione regolare della configurazione passiva e la convalida periodica della connessione.For a dependable passive backup connection solution, regular maintenance of the passive configuration and periodical validation the connection are important. È essenziale non lasciare che la configurazione VPN diventi obsoleta e periodicamente (ad ogni trimestre) Ripetere i passaggi di convalida e failover del test descritti in questo articolo durante la finestra di manutenzione.It is essential not to let the VPN configuration become stale, and to periodically (say every quarter) repeat the validation and failover test steps described in this article during maintenance window.

Per abilitare il monitoraggio e gli avvisi in base alle metriche del gateway VPN, vedere configurare gli avvisi per le metriche del gateway VPN.To enable monitoring and alerts based on VPN gateway metrics, see Set up alerts on VPN Gateway metrics.

Per accelerare la convergenza BGP in seguito a un errore ExpressRoute, configurare BFD in ExpressRoute.To expedite BGP convergence following an ExpressRoute failure, Configure BFD over ExpressRoute.