Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Sommario
Questo articolo illustra come verificare e risolvere i problemi di connettività 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 dei clienti
- Rete del provider
- Data center Microsoft
Annotazioni
Nel modello di connettività 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 consente di 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.
Informazioni generali
Il diagramma seguente illustra la connettività logica di una rete del 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 dei clienti (CES).
- Router di confine/commutatori di confine del provider (PEs) rivolti ai router di confine dei clienti.
- PE rivolti verso i router Microsoft Enterprise Edge ExpressRoute (MSEE), chiamati PE-MSEEs.
- MSEE.
- Gateway di rete virtuale.
- Dispositivo di calcolo nella rete virtuale Azure.
Questo articolo fa riferimento a questi punti di rete in base al 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à sono la condivisione dello scambio cloud, la connessione Ethernet da punto a punto o any-to-any (IPVPN).
Nel modello di connettività diretta, l'architettura non include punti di rete 3 e 4. Invece, i CE (2) si collegano direttamente agli MSEE tramite fibra scura.
Se si utilizza il modello di colocation Cloud Exchange, Ethernet point-to-point o connettività diretta, i CEs (2) stabiliscono il peering BGP (Border Gateway Protocol) con i MSEEs (5).
Se si usa il modello di connettività any-to-any (IPVPN), i PE-MSEEs (4) stabiliscono una sessione di peering BGP con gli MSEEs (5). I PE-MSEE propagano le route ricevute da Microsoft verso la rete del cliente attraverso la rete del provider di servizi IPVPN.
Annotazioni
Per garantire un'elevata disponibilità, Microsoft stabilisce una connettività parallela con completa ridondanza tra MSEE e coppie di PE-MSEE. È anche necessario creare un percorso di rete parallela completamente ridondante tra la rete dei clienti e le 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 di livello 2 ridondante tra CEs/PE-MSEEs (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
Nel portale di Azure passare alla pagina per il circuito ExpressRoute. La sezione 
della pagina elenca le informazioni di base di ExpressRoute, come illustrato nello screenshot seguente:
Nella sezione Informazioni di base di ExpressRoute, Stato del circuito mostra lo stato del circuito sul lato Microsoft e Stato del provider indica se il provider di servizi ha eseguito il provisioning del circuito.
Affinché un circuito ExpressRoute sia operativo, lo Stato circuito deve essere Abilitato e lo Stato provider deve essere Provisionato.
Annotazioni
Se lo stato del circuito è bloccato su Non abilitato, contattare il Supporto Microsoft. Se Stato del provider rimane bloccato su Non provisionato, contatta il tuo fornitore 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
Annotazioni
Se lo stato del circuito è bloccato su Non abilitato, contattare il Supporto Microsoft. Se Stato provider è bloccato su Non provisionato, contatta il fornitore di servizi.
Convalidare la configurazione del peering
Dopo che il provider di servizi effettua il provisioning del circuito ExpressRoute, è possibile creare più configurazioni di routing che usano BGP (eBGP) esterne sul circuito tra CEs/MSEE-PEs (2/4) e MSEE (5). Ogni circuito ExpressRoute può avere una o entrambe le configurazioni di peering seguenti:
- Azure peering privato: per il traffico verso reti virtuali private in Azure
- Peering Microsoft: per il traffico verso endpoint pubblici della piattaforma come servizio (PaaS) e software 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
Annotazioni
In un modello di connettività IPVPN, i provider di servizi gestiscono la responsabilità di configurare i peering (servizi di livello 3). Se il peering risulta vuoto nel portale dopo che il provider di servizi lo ha configurato, provare ad aggiornare la configurazione del circuito usando il pulsante Aggiorna nel portale. Questa operazione recupera la configurazione di instradamento corrente dal proprio circuito.
Nel portale di Azure è possibile controllare lo stato di un circuito ExpressRoute nella relativa pagina. La sezione elenca i peering ExpressRoute, come illustrato nella schermata seguente:
Nell'esempio precedente viene effettuato il provisioning del peering privato di Azure, ma non quello del peering pubblico di Azure né dei peering Microsoft. Un contesto di peering di cui è stato eseguito correttamente il provisioning riporta anche la subnet punto-punto primaria e quella secondaria. Le subnet /30 vengono usate per gli indirizzi IP delle interfacce degli MSEEs e CEs/PE-MSEE. L'elenco indica anche chi ha modificato la configurazione per l'ultima volta.
Annotazioni
Se l'abilitazione di un peering ha esito negativo, verificare se le subnet primarie e secondarie assegnate corrispondono alla configurazione nel CE/PE-MSEE collegato. Verificare inoltre che i valori VlanId, AzureASN e PeerASN sugli MSEEs corrispondano a quelli del CE/PE-MSEE associato.
Se si sceglie l'hash MD5, assicurarsi che la chiave condivisa sia la stessa nelle coppie MSEE e CE/PE-MSEE. Per motivi di sicurezza, le chiavi condivise configurate in precedenza non vengono visualizzate.
Per modificare una di queste configurazioni in un router MSEE, vedere Creare e modificare il routing per un circuito ExpressRoute.
Annotazioni
In una subnet /30 assegnata all'interfaccia, Microsoft usa il secondo indirizzo IP disponibile per l'interfaccia MSEE. Assicurarsi di assegnare il primo indirizzo IP utilizzabile al peering CE/PE-MSEE.
Verifica tramite PowerShell
Per ottenere i dettagli di configurazione per Azure peering privato, 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 delle interfacce degli MSEEs e CEs/PE-MSEE.
Per ottenere i dettagli di configurazione per il 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
Annotazioni
Se l'abilitazione di un peering ha esito negativo, verificare se le subnet primarie e secondarie assegnate corrispondono alla configurazione nel CE/PE-MSEE collegato. Verificare inoltre che i valori VlanId, AzureASN e PeerASN sugli MSEE corrispondano a quelli sul CE/PE-MSEE collegato.
Se si sceglie l'hash MD5, assicurarsi che la chiave condivisa sia la stessa nelle coppie MSEE e CE/PE-MSEE. Per motivi di sicurezza, le chiavi condivise configurate in precedenza non vengono visualizzate.
Per modificare una di queste configurazioni in un router MSEE, vedere Creare e modificare il routing per un circuito ExpressRoute.
Annotazioni
In una subnet /30 assegnata all'interfaccia, Microsoft usa il secondo indirizzo IP disponibile per l'interfaccia MSEE. Assicurati di assegnare il primo indirizzo IP utilizzabile al CE/PE-MSEE con peering.
Convalida ARP
La tabella Address Resolution Protocol (ARP) fornisce un'associazione tra l'indirizzo IP e l'indirizzo MAC per un determinato 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
- Associazione dell'indirizzo IP all'interfaccia di router ExpressRoute con l'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.
Annotazioni
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 Getting ARP tables in the Resource Manager deployment model.
Convalidare BGP e le route su 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>
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##
Annotazioni
Se lo stato del peering eBGP tra un MSEE e un CE/PE-MSEE è Active o Idle, verificare che le sottoreti peer primarie e secondarie corrispondano alla configurazione del CE/PE-MSEE collegato. Assicurarsi che i valori VlanId, AzureASN e PeerASN siano corretti sugli MSEE e corrispondano ai valori presenti 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.
Annotazioni
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à di peering privato
Testare la connettività di peering privato contando i pacchetti in arrivo al e in uscita dal perimetro di rete Microsoft del circuito ExpressRoute sui dispositivi MSEE. Questo strumento di diagnostica utilizza un elenco di controllo di accesso per contare i pacchetti che soddisfano regole specifiche, confermando la connettività.
Eseguire un test
Nel portale di Azure selezionare Diagnose e risolvere i problemi dal circuito ExpressRoute.
Selezionare Problemi di connettività e prestazioni.
Nell'elenco a discesa Informazioni sul problema riscontrato, seleziona Problemi con il peering privato.
Espandi la sezione Test della connettività di peering privato.
Eseguire il test PsPing dall'INDIRIZZO IP locale all'indirizzo IP 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 su entrambi gli MSEE: indica un traffico regolare in ingresso e in uscita. Qualsiasi perdita è a valle dagli MSEE.
Corrispondenze ricevute, ma corrispondenze inviate assenti: il traffico raggiunge Azure ma non torna. Verificare i problemi di routing nel return-path.
Inviate corrispondenze, ma nessuna corrispondenza ricevuta: il traffico raggiunge l'istanza 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 da locale a Azure, i risultati ricevuti mostrano corrispondenze, ma i risultati inviati non mostrano corrispondenze: questo risultato indica che il traffico sta arrivando a Azure ma non torna in locale. Verificare la presenza di problemi di routing del percorso di ritorno. Ad esempio, stai pubblicizzando i prefissi corretti per Azure? Una rotta definita dall'utente sostituisce i prefissi?
Se si sta testando PsPing da Azure a locale, i risultati inviati mostrano corrispondenze, ma i risultati ricevuti non mostrano corrispondenze: questo risultato indica che il traffico è in arrivo in locale ma non torna a Azure. Collaborare con il provider per scoprire perché il traffico non viene instradato alle Azure tramite il circuito ExpressRoute.
Un MSEE non mostra corrispondenze, ma l'altro mostra corrispondenze valide: questo risultato indica che un MSEE non riceve o 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.
- Esegui il test della connettività di peering privato usando l'indirizzo /32 univoco annunciato come indirizzo di destinazione on-premise ed esamina i risultati per confermare lo stato 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 Azure. Microsoft gestisce questa infrastruttura e può eseguire la manutenzione, riducendo così le prestazioni.
Per risolvere i problemi di connettività e verificare la presenza di manutenzione recente:
Nel portale di Azure selezionare Diagnose e risolvere i problemi dal circuito ExpressRoute.
Selezionare Problemi di prestazioni.
Attendere l'esecuzione della diagnostica e interpretare i risultati.
Se la manutenzione si verifica durante la perdita o la latenza dei pacchetti, potrebbe contribuire ai 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 ulteriori informazioni o assistenza, consulta i link seguenti: