Verificare la connettività di ExpressRoute
Questo articolo fornisce informazioni sulla verifica e la risoluzione dei problemi di connettività di Azure ExpressRoute. ExpressRoute estende le reti locali nel cloud Microsoft tramite una connessione privata comunemente fornita da un provider di connettività. La connettività di ExpressRoute prevede tradizionalmente tre zone di rete distinte:
- Rete del cliente
- Rete del provider
- Data center Microsoft
Nota
Nel modello di connettività di ExpressRoute Direct è possibile connettersi direttamente alla porta per i router MSEE (Microsoft Enterprise Edge). Il modello di connettività diretta include solo le zone di rete del cliente e di Microsoft.
Questo articolo consente di identificare se e dove si verifica un problema di connettività. Sarà quindi possibile richiedere supporto al team appropriato per risolvere il problema.
Importante
Questo articolo è progettato per aiutare l'utente a diagnosticare e risolvere problemi semplici. Non è pensato per sostituire il supporto tecnico Microsoft. Se non si riesce a risolvere il problema tramite le indicazioni in questo articolo, aprire un ticket di supporto per il supporto tecnico Microsoft.
Panoramica
Il diagramma seguente illustra la connettività logica della rete di un cliente alla rete Microsoft tramite ExpressRoute.
Nel diagramma precedente i numeri indicano i punti principali delle reti:
- Dispositivo di calcolo del cliente (ad esempio, un server o un PC).
- Router perimetrali del cliente (CE).
- Router/switch perimetrali del provider (PE) rivolti verso i router perimetrali del cliente.
- PE rivolti verso i router ExpressRoute Microsoft Enterprise Edge (MSEE). In questo articolo vengono chiamati PE-MSEE.
- MSEE.
- Gateway di rete virtuale.
- Dispositivo di calcolo nella rete virtuale di Azure.
Tali punti di rete vengono a volte citati in questo articolo tramite il numero associato.
A seconda del modello di connettività ExpressRoute, i punti di rete 3 e 4 possono essere commutatori (dispositivi di livello 2) o router (dispositivi di livello 3). I modelli di connettività ExpressRoute sono la condivisione di scambio cloud, la connessione Ethernet da punto a punto o any-to-any (IPVPN).
Nel modello di connettività diretta, non sono presenti punti di rete 3 e 4. I CE (2) sono invece connessi direttamente a MSEE tramite fibra scura.
Se si usa il modello di condivisione di scambio cloud, Ethernet da punto a punto o connettività diretta, i CE (2) stabiliscono il peering BGP (Border Gateway Protocol) con MSEE (5).
Se si usa il modello di connettività any-to-any (IPVPN), i PE-MSEE (4) stabiliscono il peering BGP con gli MSEE (5). I PE-MSEE propagano le route ricevute da Microsoft alla rete del cliente tramite la rete del provider di servizi IPVPN.
Nota
Per la disponibilità elevata, Microsoft stabilisce una connettività parallela completamente ridondante tra coppie di MSEE e PE-MSEE. Si consiglia anche un percorso d rete parallelo completamente ridondante tra rete del cliente e coppie PE-CE. Per altre informazioni sulla disponibilità elevata, vedere l'articolo Progettazione per la disponibilità elevata con ExpressRoute.
Le sezioni seguenti rappresentano i passaggi logici per la risoluzione dei problemi di un circuito ExpressRoute.
Verificare il provisioning e lo stato del circuito
Il provisioning di un circuito ExpressRoute stabilisce una connessione ridondante di livello 2 tra CE/PE-MSEE (2/4) e MSEE (5). Per altre informazioni su come creare, modificare, eseguire il provisioning e verificare un circuito ExpressRoute, vedere l'articolo Creare e modificare un circuito ExpressRoute.
Suggerimento
Una chiave del servizio identifica in modo univoco un circuito ExpressRoute. Se è necessario richiedere l'assistenza di Microsoft o di un partner ExpressRoute per risolvere un problema di ExpressRoute, fornire la chiave del servizio per identificare facilmente il circuito.
Verifica tramite il portale di Azure
Nel portale di Azure aprire la pagina per il circuito ExpressRoute. Nella sezione 
della pagina sono elencate le informazioni di base di ExpressRoute come illustrato nello screenshot seguente:
Nelle informazioni di base di ExpressRoute Stato circuito indica lo stato del circuito sul lato Microsoft. Stato provider indica se si tratta di un circuito con provisioning eseguito o senza provisioning sul lato del provider dei servizi.
Per consentire il funzionamento di un circuito ExpressRoute, Stato circuito deve essere Abilitato e Stato provider deve essere Provisioning eseguito.
Nota
Dopo aver configurato un circuito ExpressRoute, se Stato circuito rimane Non abilitato, contattare il supporto tecnico Microsoft. Se Stato provider rimane impostato su Senza provisioning, contattare il provider dei servizi.
Verifica tramite PowerShell
Per elencare tutti i circuiti ExpressRoute in un gruppo di risorse, usare il comando seguente:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
Suggerimento
Se si sta cercando il nome di un gruppo di risorse, è possibile ottenerlo usando il comando Get-AzResourceGroup per elencare tutti i gruppi di risorse nella sottoscrizione.
Per selezionare uno specifico circuito ExpressRoute in un gruppo di risorse, usare il comando seguente:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Di seguito è riportata una risposta di esempio:
Name : Test-ER-Ckt
ResourceGroupName : Test-ER-RG
Location : westus2
Id : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt
Etag : W/"################################"
ProvisioningState : Succeeded
Sku : {
"Name": "Standard_UnlimitedData",
"Tier": "Standard",
"Family": "UnlimitedData"
}
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
ServiceProviderNotes :
ServiceProviderProperties : {
"ServiceProviderName": "****",
"PeeringLocation": "******",
"BandwidthInMbps": 100
}
ServiceKey : **************************************
Peerings : []
Authorizations : []
Per verificare se un circuito ExpressRoute è operativo, prestare particolare attenzione ai campi seguenti:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Nota
Dopo aver configurato un circuito ExpressRoute, se Stato circuito rimane Non abilitato, contattare il supporto tecnico Microsoft. Se Stato provider rimane impostato su Senza provisioning, contattare il provider dei servizi.
Convalidare la configurazione del peering
Dopo che il provider di servizi ha completato il provisioning del circuito ExpressRoute, è possibile creare più configurazioni di routing basate su EBGP (External BGP) sul circuito ExpressRoute tra CE/MSEE-PE (2/4) e MSEE (5). Ogni circuito ExpressRoute può avere una o entrambe le configurazioni di peering seguenti:
- Peering privato di Azure: traffico verso reti virtuali private in Azure
- Peering Microsoft: traffico verso endpoint pubblici di piattaforma distribuita come servizio (PaaS) e software come un servizio (SaaS)
Per altre informazioni su come creare e modificare la configurazione di routing, vedere l'articolo Creare e modificare il routing per un circuito ExpressRoute.
Verifica tramite il portale di Azure
Nota
In un modello di connettività IPVPN, i provider di servizi gestiscono la responsabilità di configurare i peering (servizi di livello 3). In un modello di questo tipo, dopo che il provider di servizi ha configurato un peering e se il peering risulta vuoto nel portale, provare ad aggiornare la configurazione del circuito usando il pulsante di aggiornamento nel portale. Questa operazione eseguirà il pull della configurazione di routing corrente dal circuito.
Nel portale di Azure è possibile controllare lo stato di un circuito ExpressRoute nella pagina relativa al circuito. Nella sezione della pagina sono elencati i peering di ExpressRoute come illustrato nello screenshot seguente:
Nell'esempio precedente viene effettuato il provisioning del peering privato di Azure, ma non viene effettuato il provisioning dei peering pubblici e Microsoft di Azure. Per un contesto di peering di cui è stato correttamente effettuato il provisioning vengono anche elencate le subnet punto a punto primarie e secondarie. Le subnet /30 vengono usate per l'indirizzo IP dell'interfaccia degli MSEE e dei CE/PE-MSEE. Per i peering di cui è stato effettuato il provisioning, l'elenco indica anche chi ha modificato la configurazione per l'ultima volta.
Nota
Se l'abilitazione di un peering non riesce, controllare se le subnet primaria e secondaria assegnate corrispondono alla configurazione sul CE/PE-MSEE collegato. Controllare anche che siano usati i valori corretti VlanId, AzureASN e PeerASN per gli MSEE e che tali valori corrispondano a quelli usati per il CE/PE-MSEE collegato.
Se si sceglie l'hash MD5, la chiave condivisa deve essere identica nelle coppie MSEE e CE/PE-MSEE. Le chiavi condivise configurate in precedenza non vengono visualizzate per motivi di sicurezza.
Se è necessario modificare una di queste configurazioni su un router MSEE, vedere Creare e modificare il routing per un circuito ExpressRoute.
Nota
In una subnet /30 assegnata per l'interfaccia, Microsoft sceglierà il secondo indirizzo IP utilizzabile della subnet per l'interfaccia MSEE. Assicurarsi quindi che il primo indirizzo IP utilizzabile della subnet sia stato assegnato al CE/PE-MSEE con peering.
Verifica tramite PowerShell
Per ottenere i dettagli di configurazione del peering privato di Azure, usare i comandi seguenti:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
Ecco una risposta di esempio per un peering privato configurato correttamente:
Name : AzurePrivatePeering
Id : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt/peerings/AzurePrivatePeering
Etag : W/"################################"
PeeringType : AzurePrivatePeering
AzureASN : 12076
PeerASN : 123##
PrimaryPeerAddressPrefix : 172.16.0.0/30
SecondaryPeerAddressPrefix : 172.16.0.4/30
PrimaryAzurePort :
SecondaryAzurePort :
SharedKey :
VlanId : 200
MicrosoftPeeringConfig : null
ProvisioningState : Succeeded
In un contesto di peering abilitato correttamente vengono elencati i prefissi di indirizzi primari e secondari. Le subnet /30 vengono usate per l'indirizzo IP dell'interfaccia degli MSEE e dei CE/PE-MSEE.
Per ottenere i dettagli di configurazione del peering Microsoft, usare i comandi seguenti:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt
Se un peering non è configurato, viene visualizzato un messaggio di errore. Ecco una risposta di esempio quando il peering dichiarato non è configurato all'interno del circuito:
Get-AzExpressRouteCircuitPeeringConfig : Sequence contains no matching element
At line:1 char:1
+ Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzExpr...itPeeringConfig], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Network.GetAzureExpressRouteCircuitPeeringConfigCommand
Nota
Se l'abilitazione di un peering non riesce, controllare se le subnet primaria e secondaria assegnate corrispondono alla configurazione sul CE/PE-MSEE collegato. Controllare anche che siano usati i valori corretti VlanId, AzureASN e PeerASN per gli MSEE e che tali valori corrispondano a quelli usati per il CE/PE-MSEE collegato.
Se si sceglie l'hash MD5, la chiave condivisa deve essere identica nelle coppie MSEE e CE/PE-MSEE. Le chiavi condivise configurate in precedenza non vengono visualizzate per motivi di sicurezza.
Se è necessario modificare una di queste configurazioni su un router MSEE, vedere Creare e modificare il routing per un circuito ExpressRoute.
Nota
In una subnet /30 assegnata per l'interfaccia, Microsoft selezionerà il secondo indirizzo IP utilizzabile della subnet per l'interfaccia MSEE. Assicurarsi quindi che il primo indirizzo IP utilizzabile della subnet sia stato assegnato al CE/PE-MSEE con peering.
Convalidare ARP
La tabella Address Resolution Protocol (ARP) fornisce un mapping dell'indirizzo IP e dell'indirizzo MAC per un particolare peering. La tabella ARP del peering di un circuito ExpressRoute fornisce le informazioni seguenti per ogni interfaccia (primaria e secondaria):
- Mapping dell'indirizzo IP per l'interfaccia del router locale all'indirizzo MAC
- Mapping dell'indirizzo IP per l'interfaccia del router locale ExpressRoute all'indirizzo MAC (facoltativo)
- Età del mapping
Le tabelle ARP consentono di convalidare la configurazione di livello 2 e di risolvere i problemi di connettività di base di livello 2.
Nota
A seconda della piattaforma hardware, i risultati di ARP possono variare e visualizzare solo l'interfaccia locale.
Per informazioni su come visualizzare la tabella ARP di un peering ExpressRoute e su come usare le informazioni per risolvere i problemi di connettività di livello 2, vedere Recupero di tabelle ARP nel modello di distribuzione Resource Manager.
Convalidare BGP e route sul MSEE
Per ottenere la tabella di routing da MSEE sul percorso primario per il contesto di routing privato, usare il comando seguente:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****
Di seguito è riportata una risposta di esempio:
Network : 10.1.0.0/16
NextHop : 10.17.17.141
LocPrf :
Weight : 0
Path : 65515
Network : 10.1.0.0/16
NextHop : 10.17.17.140*
LocPrf :
Weight : 0
Path : 65515
Network : 10.2.20.0/25
NextHop : 172.16.0.1
LocPrf :
Weight : 0
Path : 123##
Nota
Se lo stato di un peering EBGP tra un MSEE e un CE/PE-MSEE è Attivo o Inattivo, verificare se le subnet peer primaria e secondaria assegnate corrispondono alla configurazione nel CE/PE-MSEE collegato. Controllare anche che siano usati i valori corretti VlanId, AzureASN e PeerASN per gli MSEE e che tali valori corrispondano a quelli usati per il CE/PE-MSEE collegato. Se si sceglie l'hash MD5, la chiave condivisa deve essere identica nelle coppie MSEE e CE/PE-MSEE. Se è necessario modificare una di queste configurazioni su un router MSEE, vedere Creare e modificare il routing per un circuito ExpressRoute.
Nota
Se alcune destinazioni non sono raggiungibili tramite un peering, controllare la tabella di routing dei MSEE per il contesto di peering corrispondente. Se nella tabella di routing è presente un prefisso corrispondente (potrebbe essere un IP su cui è stato eseguito il NAT), verificare se nel percorso sono presenti firewall, gruppi di sicurezza di rete o elenchi di controllo di accesso (ACL) che bloccano il traffico.
L'esempio seguente mostra la risposta del comando per un peering inesistente:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
Confermare il flusso del traffico
Per ottenere le statistiche sul traffico del percorso primario e secondario combinati (byte in entrata e in uscita) di un contesto di peering, usare il comando seguente:
Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'
Ecco un esempio di output del comando:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Ecco un esempio di output del comando per un peering inesistente:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
Testare la connettività del peering privato
Testare la connettività di peering privato contando i pacchetti in arrivo e uscita dal perimetro Microsoft del circuito ExpressRoute nei dispositivi MSEE. Questo strumento di diagnostica funziona applicando un ACL al dispositivo MSEE per contare il numero di pacchetti che soddisfano determinate regole ACL. L'uso di questo strumento consente di confermare la connettività rispondendo a domande, ad esempio:
- I pacchetti vengono recapitati ad Azure?
- Tornano indietro nella rete locale?
Eseguire un test
Per accedere allo strumento di diagnostica, selezionare Diagnostica e risolvi i problemi dal circuito ExpressRoute nel portale di Azure.
Selezionare Problemi di connettività e prestazioni.
Nell'elenco a discesa Specificare altre informazioni sul problema selezionare Problemi relativi al peering privato.
Scorrere verso il basso fino alla sezione Testare la connettività del peering privato ed espanderla.
Eseguire un test PsPing dall'indirizzo IP locale all'indirizzo IP di Azure e mantenerlo in esecuzione per la durata del test di connettività.
Compilare i campi del modulo. Assicurarsi di immettere gli stessi indirizzi IP locali e di Azure usati nel passaggio 5. Selezionare quindi Invia e attendere il caricamento dei risultati.
Interpretare i risultati
Quando i risultati sono pronti, sono disponibili due set per i dispositivi MSEE primario e secondario. Esaminare il numero di corrispondenze in ingresso e in uscita e usare gli scenari seguenti per interpretare i risultati:
Vengono visualizzate le corrispondenze di pacchetti inviati e ricevuti su entrambi i dispositivi MSEE: questo risultato è indicativo dell'integrità del traffico in ingresso e in uscita dai dispositivi MSEE nel circuito. Se la perdita si verifica on-premise o in Azure, questo accade in downstream dagli MSEE.
Se si sta testando PsPing dall'ambiente locale ad Azure, i risultati ricevuti mostrano corrispondenze, ma i risultati inviati non ne mostrano:: questo risultato indica che il traffico riesce a raggiungere Azure, ma non torna indietro verso l'ambiente locale. Verificare la presenza di problemi di routing nel percorso di ritorno. Ad esempio, si stanno annunciando i prefissi appropriati in Azure? Una route definita dall'utente esegue l'override dei prefissi?
Se si sta testando PsPing da Azure all'ambiente locale, i risultati inviati mostrano corrispondenze, ma i risultati ricevuti non ne mostrano:: questo risultato indica che il traffico riesce a raggiungere l'ambiente locale, ma non torna indietro verso Azure. Collaborare con il provider per scoprire il motivo per cui il traffico non viene instradato ad Azure tramite il circuito ExpressRoute.
Un dispositivo MSEE non mostra corrispondenze, mentre l'altro mostra corrispondenze valide: questo risultato indica che un MSEE non riceve né passa alcun traffico. Potrebbe essere offline (ad esempio, BGP/ARP è inattivo).
- È possibile eseguire test aggiuntivi per confermare il percorso non integro annunciando una route locale /32 univoca sulla sessione BGP in questo percorso.
- Eseguire "Testare la connettività di peering privato" usando l'indirizzo /32 univoco annunciato come indirizzo di destinazione locale ed esaminare i risultati per confermare l'integrità del percorso.
I risultati del test per ogni dispositivo MSEE sono simili all'esempio seguente:
src 10.0.0.0 dst 20.0.0.0 dstport 3389 (received): 120 matches
src 20.0.0.0 srcport 3389 dst 10.0.0.0 (sent): 120 matches
Nel risultato di questo test sono riportate le proprietà seguenti:
- Porta IP: 3389
- CIDR indirizzo IP locale: 10.0.0.0
- CIDR indirizzo IP di Azure: 20.0.0.0
Verificare la disponibilità del gateway di rete virtuale
Il gateway di rete virtuale di ExpressRoute facilita la connettività del piano di gestione e controllo ai servizi di collegamento privato e agli indirizzi IP privati distribuiti in una rete virtuale di Azure. Microsoft gestisce l'infrastruttura del gateway di rete virtuale,. che talvolta viene sottoposto a manutenzione.
Durante un periodo di manutenzione, le prestazioni del gateway di rete virtuale possono essere inferiori. Per risolvere i problemi di connettività alla rete virtuale e verificare se un evento di manutenzione recente ha causato la riduzione di capacità, seguire questa procedura:
Selezionare Diagnostica e risolvi i problemi dal circuito ExpressRoute nel portale di Azure.
Selezionare l'opzione Problemi di prestazioni.
Attendere l'esecuzione della diagnostica e interpretare i risultati.
Se la manutenzione è stata eseguita nel gateway di rete virtuale durante un periodo in cui si è verificata una perdita di pacchetti o una condizione di latenza. È possibile che la capacità ridotta del gateway abbia contribuito ai problemi di connettività riscontrati per la rete virtuale di destinazione. Attenersi alla procedura consigliata. Per supportare una velocità effettiva di rete superiore ed evitare problemi di connettività durante gli eventi di manutenzione futuri, è consigliabile aggiornare lo SKU del gateway di rete virtuale.
Passaggi successivi
Per maggiori informazioni o assistenza, consultare i collegamenti seguenti: