Kontrollera ExpressRoute-anslutningen
Den här artikeln hjälper dig att verifiera och felsöka Azure ExpressRoute-anslutning. ExpressRoute utökar ett lokalt nätverk till Microsoft Cloud via en privat anslutning som ofta underlättas av en anslutningsleverantör. ExpressRoute-anslutning omfattar traditionellt tre distinkta nätverkszoner:
- Kundnätverk
- Providernätverk
- Microsofts datacenter
Kommentar
I ExpressRoute Direct-anslutningsmodellen kan du ansluta direkt till porten för Microsoft Enterprise Edge-routrar (MSEE). Direktanslutningsmodellen innehåller endast dina och Microsofts nätverkszoner.
Den här artikeln hjälper dig att identifiera om och var det finns ett anslutningsproblem. Du kan sedan söka support från rätt team för att lösa problemet.
Viktigt!
Den här artikeln är avsedd att hjälpa dig att diagnostisera och åtgärda enkla problem. Det är inte avsett att ersätta Microsoft-supporten. Om du inte kan lösa ett problem med hjälp av vägledningen i den här artikeln öppnar du ett supportärende med Microsoft Support.
Översikt
Följande diagram visar den logiska anslutningen för ett kundnätverk till Microsoft-nätverket via ExpressRoute.
I föregående diagram anger siffrorna viktiga nätverkspunkter:
- Kundens beräkningsenhet (till exempel en server eller dator).
- Kundgränsroutrar (CE).
- Provider edge-routrar/växlar (PEs) som möter kundens gränsroutrar.
- PEs som möter Microsoft Enterprise Edge ExpressRoute-routrar (MSEE). Den här artikeln kallar dem PE-MSEEs.
- MSEEs.
- Virtuell nätverksgateway.
- Beräkningsenhet i det virtuella Azure-nätverket.
Ibland refererar den här artikeln till dessa nätverkspunkter efter deras associerade nummer.
Beroende på ExpressRoute-anslutningsmodellen kan nätverkspunkterna 3 och 4 vara växlar (nivå 2-enheter) eller routrar (nivå 3-enheter). ExpressRoute-anslutningsmodellerna är samlokalisering av utbyte i molnet, punkt-till-plats-Ethernet-anslutning eller valfri (IPVPN).
I direktanslutningsmodellen finns det inga nätverkspunkter 3 och 4. I stället är CEs (2) direkt anslutna till MSEE via mörk fiber.
Om molnutbytessamlokalisering, punkt-till-punkt-Ethernet eller direktanslutningsmodell används, upprättar CE:er (2) BGP-peering (Border Gateway Protocol) med MSEEs (5).
Om anslutningsmodellen alla-till-alla (IPVPN) används upprättar PE-MSEEs (4) BGP-peering med MSEEs (5). PE-MSEEs sprider de vägar som tas emot från Microsoft tillbaka till kundnätverket via IPVPN-nätverkets tjänstprovider.
Kommentar
För hög tillgänglighet etablerar Microsoft en helt redundant parallell anslutning mellan MSEE- och PE-MSEE-par. En fullständigt redundant parallell nätverkssökväg uppmuntras också mellan kundnätverket och PE/CE-par. Mer information om hög tillgänglighet finns i artikeln Designa för hög tillgänglighet med ExpressRoute.
Följande avsnitt representerar de logiska stegen i felsökningen av en ExpressRoute-krets.
Verifiera kretsetablering och tillstånd
Etablering av en ExpressRoute-krets upprättar en redundant layer 2-anslutning mellan CEs/PE-MSEEs (2/4) och MSEEs (5). Mer information om hur du skapar, ändrar, etablerar och verifierar en ExpressRoute-krets finns i artikeln Skapa och ändra en ExpressRoute-krets.
Dricks
En tjänstnyckel identifierar unikt en ExpressRoute-krets. Om du behöver hjälp från Microsoft eller från en ExpressRoute-partner för att felsöka ett ExpressRoute-problem anger du tjänstnyckeln för att enkelt identifiera kretsen.
Verifiering via Azure-portalen
Öppna sidan för ExpressRoute-kretsen i Azure-portalen. I 
avsnittet på sidan visas expressroute-grunderna, som du ser på följande skärmbild:
I ExpressRoute Essentials anger kretsstatus statusen för kretsen på Microsoft-sidan. Providerstatus anger om kretsen har etablerats eller inte etablerats på tjänstleverantörssidan.
För att en ExpressRoute-krets ska vara operativ måste Kretsstatus vara Aktiverad och Leverantörsstatus måste vara Etablerad.
Kommentar
När du har konfigurerat en ExpressRoute-krets kontaktar du Microsoft Support om kretsstatusen har fastnat i statusen Inte aktiverad. Om providerstatusen har fastnat i statusen Inte etablerad kontaktar du din tjänstleverantör.
Verifiering via PowerShell
Om du vill visa en lista över alla ExpressRoute-kretsar i en resursgrupp använder du följande kommando:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
Dricks
Om du letar efter namnet på en resursgrupp kan du hämta det med hjälp Get-AzResourceGroup av kommandot för att lista alla resursgrupper i din prenumeration.
Om du vill välja en viss ExpressRoute-krets i en resursgrupp använder du följande kommando:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Här är ett exempel:
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 : []
För att bekräfta att en ExpressRoute-krets är i drift bör du vara särskilt uppmärksam på följande fält:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Kommentar
När du har konfigurerat en ExpressRoute-krets kontaktar du Microsoft Support om kretsstatusen har fastnat i statusen Inte aktiverad. Om providerstatusen har fastnat i statusen Inte etablerad kontaktar du din tjänstleverantör.
Validera peering-konfiguration
När tjänstleverantören har slutfört etableringen av ExpressRoute-kretsen kan flera routningskonfigurationer baserade på extern BGP (eBGP) skapas via ExpressRoute-kretsen mellan CEs/MSEE-PEs (2/4) och MSEEs (5). Varje ExpressRoute-krets kan ha en eller båda av följande peeringkonfigurationer:
- Privat Peering i Azure: trafik till privata virtuella nätverk i Azure
- Microsoft-peering: trafik till offentliga slutpunkter för plattform som en tjänst (PaaS) och programvara som en tjänst (SaaS)
Mer information om hur du skapar och ändrar routningskonfiguration finns i artikeln Skapa och ändra routning för en ExpressRoute-krets.
Verifiering via Azure-portalen
Kommentar
I en IPVPN-anslutningsmodell hanterar tjänstleverantörer ansvaret för att konfigurera peerings (layer 3-tjänster). När tjänstleverantören har konfigurerat en peering i en sådan modell och om peering är tom i portalen kan du prova att uppdatera kretskonfigurationen med hjälp av uppdateringsknappen på portalen. Den här åtgärden hämtar den aktuella routningskonfigurationen från kretsen.
I Azure-portalen kan du kontrollera statusen för en ExpressRoute-krets på sidan för den kretsen. I avsnittet på sidan visas ExpressRoute-peerings, enligt följande skärmbild:
I föregående exempel etableras privat Peering i Azure, men offentliga Azure- och Microsoft-peerings etableras inte. En etablerad peeringkontext skulle också ha de primära och sekundära punkt-till-punkt-undernäten listade. Undernäten /30 används för gränssnittets IP-adress för MSEEs och CEs/PE-MSEEs. För de peerings som etableras anger listan också vem som senast ändrade konfigurationen.
Kommentar
Om det inte går att aktivera en peering kontrollerar du om de tilldelade primära och sekundära undernäten matchar konfigurationen på den länkade CE/PE-MSEE. Kontrollera också om rätt VlanIdvärden , AzureASNoch PeerASN används på MSEE:er och om dessa värden mappas till de värden som används på den länkade CE/PE-MSEE.
Om MD5-hashning väljs ska den delade nyckeln vara densamma för MSEE- och CE/PE-MSEE-par. Tidigare konfigurerade delade nycklar skulle inte visas av säkerhetsskäl.
Om du behöver ändra någon av dessa konfigurationer på en MSEE-router kan du läsa Skapa och ändra routning för en ExpressRoute-krets.
Kommentar
I ett /30-undernät som tilldelats för gränssnittet väljer Microsoft den andra användbara IP-adressen för undernätet för MSEE-gränssnittet. Se därför till att den första användbara IP-adressen för undernätet har tilldelats på peer-kopplade CE/PE-MSEE.
Verifiering via PowerShell
Använd följande kommandon för att hämta konfigurationsinformationen för privat Azure-peering:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
Här är ett exempel på ett svar för en privat peering som har konfigurerats:
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
En peeringkontext som har aktiverats skulle ha de primära och sekundära adressprefixen listade. Undernäten /30 används för gränssnittets IP-adress för MSEEs och CEs/PE-MSEEs.
Använd följande kommandon för att hämta konfigurationsinformationen för Microsoft-peering:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt
Om en peering inte har konfigurerats får du ett felmeddelande. Här är ett exempel på ett svar när den angivna peeringen inte har konfigurerats i kretsen:
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
Kommentar
Om det inte går att aktivera en peering kontrollerar du om de tilldelade primära och sekundära undernäten matchar konfigurationen på den länkade CE/PE-MSEE. Kontrollera också om rätt VlanIdvärden , AzureASNoch PeerASN används på MSEE:er och om dessa värden mappas till de värden som används på den länkade CE/PE-MSEE.
Om MD5-hashning väljs ska den delade nyckeln vara densamma för MSEE- och CE/PE-MSEE-par. Tidigare konfigurerade delade nycklar skulle inte visas av säkerhetsskäl.
Om du behöver ändra någon av dessa konfigurationer på en MSEE-router kan du läsa Skapa och ändra routning för en ExpressRoute-krets.
Kommentar
I ett /30-undernät som tilldelats för gränssnittet väljer Microsoft den andra användbara IP-adressen för undernätet för MSEE-gränssnittet. Se därför till att den första användbara IP-adressen för undernätet har tilldelats på peer-kopplade CE/PE-MSEE.
Verifiera ARP
Tabellen ARP-protokollet (Address Resolution Protocol) ger en mappning av IP-adressen och MAC-adressen för en specifik peer-koppling. ARP-tabellen för en ExpressRoute peer-koppling av krets innehåller följande information för varje gränssnitt (primärt och sekundärt):
- Mappning av IP-adressen för det lokala routergränssnittet till MAC-adressen
- Mappning av IP-adressen för det ExpressRoute routergränssnittet till MAC-adressen (valfritt)
- Ålder på mappningen
ARP-tabeller kan göra det lättare att verifiera nivå 2-konfigurationen och att felsöka grundläggande nivå 2-anslutningsproblem.
Kommentar
Beroende på maskinvaruplattformen kan ARP-resultaten variera och endast visa det lokala gränssnittet.
Information om hur du visar ARP-tabellen för en ExpressRoute-peering och hur du använder informationen för att felsöka problem med layer 2-anslutning finns i Hämta ARP-tabeller i Resource Manager-distributionsmodellen.
Verifiera BGP och vägar i MSEE
Använd följande kommando för att hämta routningstabellen från MSEE på den primära sökvägen för den privata routningskontexten:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****
Här är ett exempel:
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##
Kommentar
Om tillståndet för en eBGP-peering mellan en MSEE och en CE/PE-MSEE är aktiv eller inaktiv kontrollerar du om de tilldelade primära och sekundära peer-undernäten matchar konfigurationen på den länkade CE/PE-MSEE. Kontrollera också om rätt VlanIdvärden , AzureASNoch PeerASN används på MSEE:er och om dessa värden mappas till de värden som används på den länkade CE/PE-MSEE. Om MD5-hashning väljs ska den delade nyckeln vara densamma för MSEE- och CE/PE-MSEE-par. Om du behöver ändra någon av dessa konfigurationer på en MSEE-router kan du läsa Skapa och ändra routning för en ExpressRoute-krets.
Kommentar
Om vissa mål inte kan nås via en peering kontrollerar du routningstabellen för MSEE:erna för motsvarande peeringkontext. Om ett matchande prefix (kan vara NATed IP) finns i routningstabellen kontrollerar du om några brandväggar, nätverkssäkerhetsgrupper eller åtkomstkontrollistor (ACL) på sökvägen blockerar trafiken.
I följande exempel visas svaret från kommandot för en peering som inte finns:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
Bekräfta trafikflödet
Använd följande kommando för att hämta den kombinerade trafikstatistiken för primär och sekundär sökväg (byte in och ut) i en peeringkontext:
Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'
Här är ett exempel på utdata från kommandot:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Här är ett exempel på utdata från kommandot för en icke-existerande peering:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
Testa anslutningen för privat peering
Testa din privata peeringanslutning genom att räkna paket som kommer till och lämna Microsoft-gränsen för Din ExpressRoute-krets på MSEE-enheterna. Detta diagnostikverktyg fungerar genom att tillämpa en ACLpå MSEE för att räkna antalet paket som träffar specifika ACL-regler. Med detta verktyg kan du bekräfta anslutningen genom att svara på frågor som:
- Kommer mina paket till Azure?
- Kommer de tillbaka till den lokala miljön?
Kör ett test
Om du vill komma åt diagnostikverktyget väljer du Diagnostisera och lösa problem från Din ExpressRoute-krets i Azure-portalen.
Välj Anslut ivitets- och prestandaproblem.
I listrutan Berätta mer om problemet väljer du Problem med privat peering.
Rulla ned till avsnittet Testa privat peering-anslutning och expandera den.
Kör PsPing-testet från din lokala IP-adress till din Azure IP-adress och fortsätt köra det under anslutningstestet.
Fyll i fälten i formuläret. Se till att du anger samma lokala IP-adresser och Azure IP-adresser som du använde i steg 5. Välj sedan Skicka och vänta tills resultatet har lästs in.
Tolka resultaten
När resultatet är klart har du två uppsättningar av dem för de primära och sekundära MSEE-enheterna. Granska antalet matchningar in och ut och använd följande scenarier för att tolka resultatet:
Du ser paketmatchningar som skickats och tagits emot på båda MSEE:er: Det här resultatet indikerar felfri trafik inkommande till och utgående trafik från MSEE:er på kretsen. Om förlust sker antingen lokalt eller i Azure sker det nedströms från MSEE:erna.
Om du testar PsPing från lokal plats till Azure visar mottagna resultat matchningar, men skickade resultat visar inga matchningar: Detta resultat anger att trafiken kommer in till Azure men inte återgår till den lokala miljön. Kontrollera om det finns routningsproblem för returvägar. Annonserar du till exempel lämpliga prefix till Azure? Är en användardefinierad väg (UDR) åsidosättande prefix?
Om du testar PsPing från Azure till lokalt visar skickade resultat matchningar, men mottagna resultat visar inga matchningar: Det här resultatet indikerar att trafik kommer in på plats men inte återvänder till Azure. Kontakta din leverantör för att ta reda på varför trafik inte dirigeras till Azure via din ExpressRoute-krets.
En MSEE visar inga matchningar, men den andra visar bra matchningar: Det här resultatet anger att en MSEE inte tar emot eller skickar någon trafik. Det kan vara offline (till exempel är BGP/ARP nere).
- Du kan köra ytterligare tester för att bekräfta den felaktiga sökvägen genom att annonsera en unik/32 lokal väg över BGP-sessionen på den här sökvägen.
- Kör "Testa privat peering-anslutning" med den unika /32 som annonseras som den lokala måladressen och granska resultaten för att bekräfta sökvägens hälsotillstånd.
Testresultaten för varje MSEE-enhet ser ut som i följande exempel:
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
Det här testresultatet har följande egenskaper:
- IP-port: 3389
- Lokal IP-adress CIDR: 10.0.0.0
- Azure IP-adress CIDR: 20.0.0.0
Kontrollera tillgängligheten för den virtuella nätverksgatewayen
Den virtuella ExpressRoute-nätverksgatewayen underlättar hanterings- och kontrollplanets anslutning till privata länktjänster och privata IP-adresser som distribueras till ett virtuellt Azure-nätverk. Microsoft hanterar infrastrukturen för den virtuella nätverksgatewayen och genomgår ibland underhåll.
Under en underhållsperiod kan prestandan för den virtuella nätverksgatewayen minska. Följ dessa steg för att felsöka anslutningsproblem till det virtuella nätverket och se om en underhållshändelse nyligen orsakade en minskning av kapaciteten:
Välj Diagnostisera och lösa problem från din ExpressRoute-krets i Azure-portalen.
Välj alternativet Prestandaproblem.
Vänta tills diagnostiken körs och tolka resultatet.
Om underhåll utfördes på din virtuella nätverksgateway under en period då du upplevde paketförlust eller svarstid. Det är möjligt att den minskade kapaciteten för gatewayen bidrog till anslutningsproblem som du upplever för det virtuella målnätverket. Följ de rekommenderade stegen. Om du vill ha stöd för ett högre nätverksdataflöde och undvika anslutningsproblem under framtida underhållshändelser bör du överväga att uppgradera SKU:n för den virtuella nätverksgatewayen.
Nästa steg
Mer information eller hjälp finns på följande länkar: