Verificare la connettività di ExpressRoute
Questo articolo fornisce informazioni sulla verifica e la risoluzione dei problemi di connettività di Azure ExpressRoute. ExpressRoute estende una rete locale in Microsoft Cloud tramite una connessione privata facilitata da un provider di connettività. La connettività ExpressRoute prevede 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). Questo modello include solo la rete e le zone di rete Microsoft.
Questo articolo illustra come identificare i problemi di connettività e richiedere supporto al team appropriato per risolverli.
Importante
Questo articolo è progettato per aiutare l'utente a diagnosticare e risolvere problemi semplici. Non è una sostituzione del supporto Tecnico Microsoft. Se non è possibile risolvere un problema usando queste indicazioni, aprire un ticket di supporto con supporto tecnico Microsoft.
Panoramica
Il diagramma seguente illustra la connettività logica della rete di un cliente alla rete Microsoft tramite ExpressRoute.
Nel diagramma i numeri indicano i punti di rete chiave:
- Dispositivo di calcolo del cliente (ad esempio, un server o un PC).
- Router perimetrali del cliente (CE).
- Router perimetrali/commutatori perimetrali del provider (PEs) rivolti ai router perimetrali dei clienti.
- Router ExpressRoute (MSEE) di Microsoft Enterprise Edge, chiamati PE-MSEEs.
- MSEE.
- Gateway di rete virtuale.
- Dispositivo di calcolo nella rete virtuale di Azure.
Questi punti di rete fanno riferimento al numero associato in tutto l'articolo.
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à sono la condivisione dello 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 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 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, effettuare il provisioning e verificare un circuito ExpressRoute, vedere Creare e modificare un circuito ExpressRoute.
Suggerimento
Una chiave del servizio identifica in modo univoco un circuito ExpressRoute. Se è necessaria assistenza da Microsoft o da un partner ExpressRoute per risolvere un problema, fornire la chiave del servizio per identificare facilmente il circuito.
Verifica tramite il portale di Azure
Nella portale di Azure passare alla pagina per il circuito ExpressRoute. Nella sezione 
della pagina sono elencate le informazioni di base di ExpressRoute come illustrato nello screenshot seguente:
Negli elementi di base di ExpressRoute lo stato del circuito indica lo stato del circuito sul lato Microsoft e lo stato del provider indica se il provisioning del circuito è stato effettuato dal provider di servizi.
Per consentire il funzionamento di un circuito ExpressRoute, Stato circuito deve essere Abilitato e Stato provider deve essere Provisioning eseguito.
Nota
Se lo stato del circuito è bloccato in Non abilitato, contattare supporto tecnico Microsoft. Se lo stato del provider è bloccato in Non sottoposto a provisioning, contattare il provider di 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
Per trovare il nome di un gruppo di risorse, usare il Get-AzResourceGroup comando per elencare tutti i gruppi di risorse nella sottoscrizione.
Per ottenere i dettagli di un circuito ExpressRoute specifico 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 che un circuito ExpressRoute sia operativo, verificare che i campi seguenti siano impostati correttamente:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Nota
Se lo stato del circuito è bloccato in Non abilitato, contattare supporto tecnico Microsoft. Se lo stato del provider è bloccato in Non sottoposto a provisioning, contattare il provider di servizi.
Convalidare la configurazione del peering
Dopo che il provider di servizi ha effettuato il provisioning del circuito ExpressRoute, è possibile creare più configurazioni di routing usando BGP (eBGP) esterno sul circuito tra CEs/MSEE-PEs (2/4) e MSEE (5). Ogni circuito ExpressRoute può avere una o entrambe le configurazioni di peering seguenti:
- Peering privato di Azure: per il traffico verso reti virtuali private in Azure
- Peering Microsoft: per il traffico verso endpoint pubblici della piattaforma distribuita come servizio (PaaS) e software distribuita come servizio (SaaS)
Per altre informazioni sulla creazione e la modifica delle configurazioni di routing, vedere 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). Se il peering è vuoto nel portale dopo averla configurata dal provider di servizi, 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.
Nella portale di Azure è possibile controllare lo stato di un circuito ExpressRoute nella relativa pagina. La sezione elenca i peering ExpressRoute, come illustrato nello screenshot seguente:
Nell'esempio precedente viene effettuato il provisioning del peering privato di Azure, ma i peering pubblici e Microsoft di Azure non sono. Un contesto di peering con provisioning completato elenca anche le subnet da punto a punto primario e secondario. Le subnet /30 vengono usate per gli indirizzi IP dell'interfaccia degli account del servizio gestito e delle CEs/PE-MSEE. 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. Verificare inoltre che i VlanIdvalori , AzureASNe PeerASN negli msee corrispondano a quelli nel CE/PE-MSEE collegato.
Se si seleziona l'hash MD5, assicurarsi che la chiave condivisa sia la stessa nelle coppie MSEE e CE/PE-MSEE. Le chiavi condivise configurate in precedenza non verranno 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 userà il secondo indirizzo IP utilizzabile per l'interfaccia MSEE. Verificare che il primo indirizzo IP utilizzabile sia assegnato al peering CE/PE-MSEE.
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
Un contesto di peering abilitato correttamente elenca i prefissi di indirizzo primario e secondario. Le subnet /30 vengono usate per gli indirizzi IP dell'interfaccia degli account del servizio gestito e delle CEs/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. Verificare inoltre che i VlanIdvalori , AzureASNe PeerASN negli msee corrispondano a quelli nel CE/PE-MSEE collegato.
Se si seleziona l'hash MD5, assicurarsi che la chiave condivisa sia la stessa nelle coppie MSEE e CE/PE-MSEE. Le chiavi condivise configurate in precedenza non verranno 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 userà il secondo indirizzo IP utilizzabile per l'interfaccia MSEE. Verificare che il primo indirizzo IP utilizzabile sia assegnato al peering CE/PE-MSEE.
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 recuperare la tabella di routing da MSEE nel percorso primario per il contesto di routing privato, usare il comando seguente:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName <CircuitName> -PeeringType AzurePrivatePeering -ResourceGroupName <ResourceGroupName>
Esempio di risposta:
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 del peering eBGP tra un MSEE e un CE/PE-MSEE è Attivo o Inattiva, verificare che le subnet peer primarie e secondarie corrispondano alla configurazione nel CE/PE-MSEE collegato. Verificare che i VlanIdvalori , AzureASNe PeerASN siano corretti negli msee e corrispondano a quelli nel CE/PE-MSEE collegato. Se si usa l'hash MD5, la chiave condivisa deve essere la stessa nelle coppie MSEE e CE/PE-MSEE. Per le modifiche di configurazione in 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 route MSEE per il contesto di peering corrispondente. Se è presente un prefisso corrispondente, assicurarsi che non siano presenti firewall, gruppi di sicurezza di rete o ACL che bloccano il traffico.
Risposta di esempio per un peering inesistente:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Confermare il flusso del traffico
Per ottenere statistiche sul traffico (byte in ingresso e uscita) per un contesto di peering, usare il comando seguente:
Get-AzExpressRouteCircuitStats -ResourceGroupName <ResourceGroupName> -ExpressRouteCircuitName <CircuitName> -PeeringType 'AzurePrivatePeering'
Output di esempio:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Output di esempio per un peering inesistente:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Testare la connettività del peering privato
Testare la connettività di peering privato contando i pacchetti in arrivo e lasciando il perimetro Microsoft del circuito ExpressRoute nei dispositivi MSEE. Questo strumento di diagnostica usa un elenco di controllo di accesso per contare i pacchetti che toccano regole specifiche, confermando la connettività.
Eseguire un test
Nella portale di Azure selezionare Diagnostica e risoluzione dei problemi dal circuito ExpressRoute.
Selezionare Problemi di connettività e prestazioni.
Nell'elenco a discesa Informazioni sul problema riscontrato selezionare Problemi con il peering privato.
Espandere la sezione Test private-peering connectivity (Test private-peering connectivity ).
Eseguire il test PsPing dall'indirizzo IP locale all'indirizzo IP di Azure e mantenerlo in esecuzione durante il test.
Compilare i campi del modulo con gli stessi indirizzi IP usati nel passaggio 5, quindi selezionare Invia e attendere i risultati.
Interpretare i risultati
Esaminare i risultati per i dispositivi MSEE primari e secondari:
Corrispondenze inviate e ricevute in entrambi gli ambienti del servizio gestito: indica il traffico integro in ingresso e in uscita. Qualsiasi perdita è downstream dagli account del servizio gestito.
Corrispondenze ricevute ma non corrispondenze inviate: il traffico sta raggiungendo Azure ma non restituisce. Controllare i problemi di routing del percorso restituito.
Corrispondenze inviate ma non corrispondenze ricevute: il traffico raggiunge l'ambiente locale ma non torna ad Azure. Collaborare con il provider per risolvere il problema.
Un MSEE non mostra corrispondenze, l'altro mostra corrispondenze valide: indica che un MSEE non riceve o passa il traffico. Potrebbe essere offline.
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
Verificare la disponibilità del gateway di rete virtuale
Il gateway di rete virtuale ExpressRoute gestisce la connettività ai servizi di collegamento privato e agli INDIRIZZI IP privati in una rete virtuale di Azure. Microsoft gestisce questa infrastruttura e potrebbe eseguire manutenzione, riducendo le prestazioni.
Per risolvere i problemi di connettività e verificare la presenza di manutenzione recente:
Nella portale di Azure selezionare Diagnostica e risoluzione dei problemi dal circuito ExpressRoute.
Selezionare Problemi di prestazioni.
Attendere l'esecuzione della diagnostica e interpretare i risultati.
Se la manutenzione si è verificata durante la perdita o la latenza dei pacchetti, potrebbe aver contribuito a problemi di connettività. Seguire i passaggi consigliati e prendere in considerazione l'aggiornamento dello SKU del gateway di rete virtuale per supportare una maggiore velocità effettiva ed evitare problemi futuri.
Passaggi successivi
Per maggiori informazioni o assistenza, consultare i collegamenti seguenti: