Felsöka ExpressRoute-anslutning

  • 8 minuter

ExpressRoute fungerar via en privat fiberoptisk anslutning för att ge en snabbare anslutning till Azure jämfört med att ansluta direkt via Internet. I den här lektionen får du lära dig hur du felsöker problem som kan uppstå med ExpressRoute-anslutning.

Följande diagram visar anslutningen mellan ditt nätverk (kundnätverk) och Azure (Microsoft Datacenter):

Screenshot showing connectivity between your network (Customer network) and Azure (Microsoft Datacenter).

Innan du kan använda ExpressRoute måste du ha ett aktivt Microsoft Azure-konto.

Om du också vill ansluta till Microsoft 365-tjänster behöver du minst ett Microsoft 365-konto. Microsoft 365 är dock optimerat för att ansluta via Internet, så rekommenderas endast för specifika fall.

Du måste också arbeta med en tjänstleverantör för att hantera den privata anslutningen.

Prenumeration som krävs Endast Microsoft Azure Microsoft Azure och Microsoft 365
Microsoft Azure-konto Rekommenderat Rekommenderat
Microsoft 365 Rekommenderas inte Rekommenderat

Gatewayer och SKU:er

ExpressRoute använder en virtuell gateway för att ansluta ditt virtuella Azure-nätverk till ditt lokala nätverk.

En virtuell nätverksgateway är två eller flera virtuella datorer som är distribuerade till ett gatewayundernät. De virtuella gatewaydatorerna innehåller routningstabeller och kör specifika gatewaytjänster.

Det finns två typer av gateway – VPN och ExpressRoute. VPN-gatewayer skickar krypterad trafik via Internet. ExpressRoute-gatewayer skickar trafik över en privat, okrypterad anslutning. När du konfigurerar gatewayen måste du ange typen som: ExpressRoute.

Varje virtuellt nätverk kan ha en gateway för varje typ, så du kan konfigurera:

  • En virtuell nätverksgateway för VPN-trafik: skriv Vpn.

  • En virtuell nätverksgateway för ExpressRoute-trafik: skriv ExpressRoute.

Du kan också konfigurera den gateway-SKU som du vill använda. SKU:er refererar till den bandbredd som allokeras till gatewayen. En högre gateway-SKU tillåter fler processorer och dataflöde för nätverksbandbredd. ExpressRoute-gatewayer stöder följande SKU:er:

  • Standard

  • HighPerformance

  • UltraPerformance

  • ErGw1Az

  • ErGw2Az

  • ErGw3Az

Om du vill uppgradera en gateway-SKU kan du använda följande PowerShell-cmdlet:

Resize-AzVirtualNetworkGateway

Du kan också ändra konfigurationen i konfigurationsfönstret för virtuell nätverksgateway i Azure-portalen. Följande uppgraderingar stöds:

  • Standard till hög prestanda

  • Standard-till-ultraprestanda

  • Hög prestanda till ultraprestanda

  • ErGw1Az to ErGw2Az

  • ErGw1Az to ErGw3Az

  • ErGw2Az to ErGw3Az

  • Standardvärdet är Standard

Följande nedgraderingar stöds:

  • Hög prestanda till standard

  • ErGw2Az to ErGw1Az

Om uppgraderingen eller nedgraderingen du behöver inte stöds tar du bort och återskapar gatewayen.

Innan du kan skapa en ExpressRoute-gateway måste du upprätta ett gatewayundernät som innehåller IP-adresserna för undernätet.

I Azure-portalen väljer du ditt virtuella nätverk, väljer Undernät och sedan Skapa gatewayundernät. När du konfigurerar IP-adressintervallet för gatewayundernätet behöver en konfiguration med en ExpressRoute-gateway och en VPN-gateway samexisterande ett stort gatewayundernät. Du bör också se till att gatewayundernätet innehåller tillräckligt med IP-adresser för att inkludera framtida ytterligare konfigurationer. Microsoft rekommenderar ett gateway-undernät på /27 eller större (/27, /26 och så vidare).

  • Gateway-undernätet används endast för ExpressRoute. Tilldela inte något annat till gatewayundernätet.

  • Den måste ha namnet GatewaySubnet.

  • Användardefinierade vägar med målet 0.0.0.0/0 stöds inte.

  • NSG:er på GatewaySubnet stöds inte.

  • Ange BGP Route-spridning till Aktiverad. Om detta är inställt på Inaktiverad fungerar inte gatewayen.

När du skapar din virtuella nätverksgateway distribueras virtuella gatewaydatorer till gatewayundernätet och konfigureras med nödvändiga ExpressRoute-gatewayinställningar.

Kommentar

Det kan ta upp till 45 minuter innan gatewayen skapas och är redo att användas.

Avgöra om en ExpressRoute-krets är i drift

I Azure-portalen visar du befintliga ExpressRoute-kretsar genom att välja Alla tjänster>Nätverk>ExpressRoute-kretsar från den vänstra menyn.

Screenshot of Expressroute circuits settings.

Alla ExpressRoute-kretsar som skapats i prenumerationen visas här.

Screenshot of Expressroute circuits list.

För att kretsen ska fungera måste du skicka tjänstnyckeln till tjänstleverantören. Varje tjänstnyckel är specifik för en krets. Välj den relevanta kretsen och leta upp tjänstnyckelfältet för leverantören på sidan Översikt .

Screenshot of service key field.

Providerstatusen visar etableringstillståndet på tjänstleverantörssidan.

Kretsstatus visar tillståndet för etablering på Microsoft-sidan.

När du skapar en ny ExpressRoute-krets är kretsen i följande tillstånd:

Providerstatus: Inte etablerad kretsstatus: Aktiverad

Kretsen ändras när tjänstleverantören etablerar den åt dig:

Providerstatus: Etableringskretsstatus : Aktiverad

ExpressRoute-kretsen fungerar när den är i följande tillstånd:

Providerstatus: Etablerad kretsstatus: Aktiverad

Du kan också kontrollera etableringsstatusen med hjälp av Azure PowerShell-cmdleten:

Get-AzExpressRouteCircuit -ResourceGroupName "Test-Resource" -Name "Test-Circuit"

Utdata visar både kretsetableringstillståndet och etableringstillståndet för tjänstleverantören.

Om kretsstatusen har fastnat på Inte aktiverad kontaktar du Microsoft Support.

Om providerstatusen har fastnat på Inte etablerad kontaktar du din tjänstleverantör.

Verifiera peeringkonfigurationen för kretsen

Varje ExpressRoute-krets kan ha privat Azure-peering och Microsoft-peering. Privat Peering i Azure är trafik till privata virtuella nätverk i Azure. Microsoft-peering är trafik till offentliga slutpunkter för PaaS och SaaS.

Peeringarna konfigureras av tjänstleverantören. Om peering i portalen fortfarande är tom kan du prova att använda uppdatering för att hämta den aktuella routningskonfigurationen från kretsen.

Status för en ExpressRoute-kretspeering kan kontrolleras i Azure-portalen på sidan Översikt över ExpressRoute-krets. Alla ExpressRoute-peerings visas under avsnittet Peerings .

Screenshot of Expressroute peerings.

I skärmbilden ovan etableras privat Peering i Azure, men offentliga Azure- och Microsoft-peerings är det inte. En etablerad peering skulle också ha de primära och sekundära punkt-till-punkt-undernäten listade.

Om det inte går att aktivera en peering kontrollerar du om de primära och sekundära undernät som tilldelats matchar konfigurationen på den länkade CE/PE-MSEE. Kontrollera också om rätt VlanId, AzureASN och PeerASN används på MSEE:er och om dessa värden mappas till de 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 PE-MSEE/CE-paret. Av säkerhetsskäl skulle den tidigare konfigurerade delade nyckeln inte visas.

Kommentar

Peeringplatsen anger den fysiska plats där du peering med Microsoft. Egenskapen Plats anger var Azure-nätverksresursprovidern finns. Det är bra att välja en nätverksresursprovider geografiskt nära kretsens peeringplats.

Du kan också testa din privata peeringanslutning genom att räkna paket som anländer och lämna Microsoft Enterprise Edge-enheterna (MSEE). Med det här verktyget kan du bekräfta anslutningen genom att besvara frågor som:

  • Kommer mina paket till Azure?

  • Kommer de tillbaka till mitt lokala nätverk?

Om du vill komma åt det här diagnostikverktyget från Azure-portalen väljer du din ExpressRoute-krets och väljer sedan Diagnostisera och lösa problem.

Verifiera att vägarna är aktiva och konfigurerade korrekt

Du kan kontrollera att vägarna är aktiva och konfigurerade korrekt genom att testa peeringanslutningen. Räkna de paket som anländer och lämna gränsen för Din ExpressRoute-krets på Microsoft Enterprise Edge-enheter (MSEE). Det här diagnostikverktyget fungerar genom att tillämpa en åtkomstkontrollista (ACL) på MSEE för att räkna antalet paket som träffar specifika ACL-regler. Med det här verktyget kan du bekräfta att anslutningen fungerar som förväntat.

  1. Om du vill komma åt det här diagnostikverktyget väljer du Diagnostisera och lösa problem från Din ExpressRoute-krets i Azure-portalen.

    Screenshot showing the diagnose and solve problems from the ExpressRoute circuit in the Azure portal.

  2. Välj Anslut ivitetsproblem under Vanliga problem.

    Screenshot of connectivity issues.

  3. I listrutan för Berätta mer om problemet du upplever väljer du Anslut ivity to Azure Private, Azure Public eller Dynamics 365-tjänster.

    Screenshot showing connection to Azure Private, Azure Public, or Dynamics 365 services.

  4. Rulla ned till avsnittet Testa din privata peeringanslutning och expandera den.

    Screenshot showing Testing of private peering connectivity.

  5. Kör PsPing-testet från din lokala IP-adress till din Azure IP-adress och håll det igång under anslutningstestet.

  6. Fyll i fälten i formuläret och ange samma lokala ip-adresser och Azure IP-adresser som användes tidigare. Välj Skicka och vänta på resultatet. När dina resultat är klara kan du läsa informationen för att tolka dem nedan.

    Screenshot of connectivity test.

    Du har två uppsättningar resultat 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 skickas och tas emot på båda MSEE:erna: Detta anger felfri trafik inkommande till och utgående trafik från MSEE på kretsen. Om förlust sker antingen lokalt eller i Azure sker det nedströms från MSEE.

    • Om testning av PsPing från lokalt till Azure (mottaget) resultat visar matchningar, men skickade resultat visar INGA matchningar: Detta indikerar att trafiken kommer in till Azure men inte återgår till den lokala miljön. Kontrollera om det finns problem med routning av retursökväg. Kontrollera om du annonserar lämpliga prefix till Azure. Kontrollera om det finns ett UDR-åsidosättande prefix.

    • Om testning av PsPing från Azure till lokala (skickade) resultat visar INGA matchningar, men (mottagna) resultat visar matchningar: Detta indikerar att trafiken kommer till lokalt, men inte kommer tillbaka. Du bör samarbeta med din leverantör för att ta reda på varför trafiken inte dirigeras till Azure via din ExpressRoute-krets.

    • En MSEE visar INGA matchningar, medan den andra visar bra matchningar: Detta anger att en MSEE inte tar emot eller skickar någon trafik. Kontrollera om den är offline, till exempel BGP/ARP nedåt.

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 Address CIDR: 20.0.0.0

Återställa en ExpressRoute-krets

När en åtgärd på en ExpressRoute-krets inte slutförs kan kretsen hamna i ett "misslyckat" tillstånd. Du kan återställa en misslyckad ExpressRoute-krets med Hjälp av Azure PowerShell. Du behöver den senaste versionen av Azure Resource Manager PowerShell-cmdletar.

  1. Öppna PowerShell-konsolen med utökade privilegier och anslut till ditt konto. Använd följande exempel för att ansluta:

    Connect-AzAccount

  2. Om du har flera Azure-prenumerationer kontrollerar du kontots prenumerationer.

    Get-AzSubscription

  3. Ange den prenumeration som du vill använda.

    Select-AzSubscription -SubscriptionName "Replace_with_your_subscription_name"

  4. Kör följande kommandon för att återställa en krets som är i ett feltillstånd:

    $ckt = Get-AzExpressRouteCircuit -Name "ExpressRouteARMCircuit" -ResourceGroupName "ExpressRouteResourceGroup"

Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

Kretsen bör nu återställas.

Felsöka problem med asymmetrisk routning

Asymmetrisk routning är när den returnerade nätverkstrafiken tar en annan sökväg än det ursprungliga utgående flödet. Om du till exempel har en internetsökväg och en privat sökväg som går till samma mål. Det händer också när du har flera privata sökvägar som är anslutna till samma mål.

Traceroute är det bästa sättet att kontrollera att nätverkstrafik skickas via rätt väg.

När du ansluter via Azure ExpressRoute har du flera länkar till Microsoft. Du har din befintliga Internetanslutning och ExpressRoute-anslutningen. Trafik som är avsedd för Microsoft kan gå via Internetanslutningen men returneras via ExpressRoute-anslutningen. Alternativt kan trafiken gå via ExpressRoute men returnera via Internetsökvägen.

Du får mer specifika IP-adresser från ExpressRoute-kretsen. Så när trafik från nätverket går till Microsoft för tjänster som erbjuds via ExpressRoute dirigeras trafiken till ExpressRoute-anslutningen.

Det finns två alternativ när du löser asymmetrisk routning – med routning eller med hjälp av källbaserad NAT (SNAT).

Med routningsalternativet annonserar du dina offentliga IP-adresser till lämpliga WAN-länkar (Wide Area Network). Om du till exempel vill använda Internet för autentiseringstrafik och ExpressRoute för e-posttrafik måste du inte annonsera dina offentliga IP-adresser för Active Directory Federation Services (AD FS) (AD FS) via ExpressRoute. Se också till att inte exponera din lokala AD FS-server för IP-adresser som routern tar emot via ExpressRoute. Vägar som tas emot via ExpressRoute är mer specifika, så de gör ExpressRoute till den föredragna sökvägen för autentiseringstrafik till Microsoft.

Om du vill använda ExpressRoute för autentisering annonserar du offentliga AD FS-IP-adresser via ExpressRoute utan NAT. Detta skickar den trafik som kommer från Microsoft via ExpressRoute till din lokala AD FS-server. Returtrafiken från nätverket som går till Microsoft använder ExpressRoute eftersom det är den föredragna vägen via Internet.

Du kan också använda SNAT för att förhindra asymmetrisk routning. Om du till exempel vill skicka SMTP-trafik via Internet ska du inte annonsera den offentliga IP-adressen för en lokal SMTP-server via ExpressRoute.

En begäran från Microsoft som går till din lokala SMTP-server passerar internet. Du använder SNAT för att skicka den inkommande begäran till en intern IP-adress. Returtrafiken från SMTP-servern går till gränsbrandväggen (som du använder för NAT) i stället för via ExpressRoute, vilket säkerställer att returtrafiken tar internetsökvägen.

Felsöka vägfiltrering

När du konfigurerar peering på ExpressRoute-kretsen etablerar gränsroutrarna ett par BGP-sessioner (Border Gateway Protocol) med gränsroutrarna via anslutningsleverantören. I det här läget annonseras inga vägar till nätverket. Om du vill aktivera routningsannonser till nätverket måste du konfigurera ett vägfilter.

Med ett routningsfilter kan du identifiera tjänster som du vill använda. Det är en lista över tillåtna BGP-communityvärden. När en vägfilterresurs har definierats och kopplats till en ExpressRoute-krets annonseras alla prefix som mappar till BGP-communityvärdena till nätverket.

Du måste ha behörighet att använda Microsoft 365-tjänster via ExpressRoute för att bifoga routningsfilter med Microsoft 365-tjänster. Om du inte har den här auktoriseringen misslyckas åtgärden.

BGP-communityvärden som är associerade med tjänster som är tillgängliga via Microsoft-peering är tillgängliga här: Krav för ExpressRoute-routning.

Ett vägfilter kan bara ha en regel och måste vara av typen Tillåt. Du kan associera en lista över BGP-communityvärden som är associerade med regeln.

Skapa en filterregel:

  • Om du vill lägga till och uppdatera regler väljer du fliken Hantera regel för vägfiltret.

    Screenshot of Manage rule tab.

  • I listrutan väljer du de tillåtna tjänstgrupper som du vill ansluta till. Spara regeln när du är klar.

Screenshot of Rule settings.

Felsöka redundanta konfigurationer

Varje ExpressRoute-krets har ett redundant par med korsanslutningar för att säkerställa hög tillgänglighet. Om en av korsanslutningarna misslyckas förlorar du inte anslutningen. Den redundanta anslutningen ger anslutning och hög tillgänglighet.

Varje Azure VPN-gateway består av två instanser, som båda är i aktivt vänteläge. När underhåll eller oplanerade avbrott inträffar för den aktiva instansen tar standby-instansen över (redundansväxla) automatiskt.

Felsöka routningsuppdateringar

Nätverksroutning är det sätt som nätverkstrafiken avgör dess sökväg för att nå ett mål. Routningstabeller används för att fastställa routningsvägar genom att visa information om nätverkstopologi. Om ditt virtuella nätverk innehåller en virtuell nätverksinstallation (NVA) måste du konfigurera och uppdatera routningstabellerna manuellt.

Med Azure Route Server kan du konfigurera, underhålla och distribuera NVA:er i ditt virtuella nätverk. Routningsservern håller även adressinformationen för det virtuella nätverket uppdaterad. Routningsservern eliminerar de administrativa kostnaderna för att underhålla routningstabeller.

Du kan också definiera statiska vägar som åsidosätter Azures standardvägar. Eller så kan du lägga till ytterligare vägar i ett undernäts routningstabell. Du skapar anpassade vägar genom att antingen skapa användardefinierade vägar eller genom att utbyta BGP-vägar (Border Gateway Protocol ) mellan din lokala nätverksgateway och en virtuell Azure-nätverksgateway.

Om du vill felsöka routningsuppdateringar provar du följande:

  • Distribuera inte en virtuell installation i samma undernät som routningstabellen som dirigerar trafik genom den. Detta kan resultera i routningsloopar, vilket innebär att trafiken aldrig lämnar undernätet.

  • Se till att en privat IP-adress för nästa hopp har direktanslutning utan routning via ExpressRoute Gateway eller Virtual WAN. Om du ställer in nästa hopp till en IP-adress utan direkt anslutning resulterar det i en ogiltig användardefinierad routningskonfiguration.

Identifiera rotorsaken till problem med ExpressRoute-svarstid

För att felsöka svarstidsproblem med ExpressRoute innehåller Azure Anslut ivity Toolkit ett verktyg som heter iPerf.

Du använder iPerf för grundläggande prestandatester genom att kopiera filerna till en katalog på värden. Följ dessa steg för att testa prestanda:

  1. Installera PowerShell-modulen.

    (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression

    Det här kommandot laddar ned PowerShell-modulen och installerar den lokalt.

  2. Installera de program som stöds.

    Install-LinkPerformance

    Det här AzureCT-kommandot installerar iPerf och PSPing i en ny katalog, "C:\ACTTools". Den öppnar även Windows-brandväggsportarna för att tillåta ICMP- och port 5201-trafik (iPerf).

  3. Kör prestandatestet.

    Först måste du installera och köra iPerf i serverläge på fjärrvärden. Kontrollera att fjärrvärden lyssnar på antingen 3389 (RDP för Windows) eller 22 (SSH för Linux) och tillåter trafik på port 5201 för iPerf. Om fjärrvärden är Windows installerar du AzureCT och kör kommandot Install-LinkPerformance. Kommandot konfigurerar iPerf och nödvändiga brandväggsregler.

    När fjärrdatorn är klar öppnar du PowerShell på den lokala datorn och startar testet:

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10

    Det här kommandot kör en serie samtidiga belastnings- och svarstidstester för att beräkna bandbreddskapaciteten och svarstiden för nätverkslänken.

  4. Granska testernas utdata.

De detaljerade resultaten av iPerf-tester finns i enskilda textfiler i Katalogen AzureCT-verktyg i "C:\ACTTools".

PowerShell-utdataformatet ser ut ungefär så här:

Screenshot of PowerShell output of test.

Om prestandatestet inte ger de resultat som du förväntade dig använder du en stegvis process för att lösa problemet.

Börja med att utmana dina antaganden. Om du har en ExpressRoute-krets på 1 Gbps och 100 ms svarstid är det inte rimligt att förvänta sig hela 1 Gbps av trafik, med tanke på egenskaperna för TCP över länkar med hög svarstid.

Börja sedan vid kanterna mellan routningsdomäner för att försöka isolera problemet till en enda större routningsdomän. Du kan börja på Företagsnätverk, WAN eller Azure Network. Se till att du har rimlig anledning att kontakta din tjänstleverantör eller ISP, eftersom detta ligger utanför din kontroll. Det kan fördröja en korrigering som är under din kontroll.

När du har identifierat den större routningsdomänen som verkar innehålla problemet skapar du ett diagram. Om du ser området i ett diagram kan du arbeta metodiskt genom att planera punkter att testa. Dela upp nätverket i segment för att begränsa problemet och uppdatera diagrammet när du får resultat.

Glöm inte heller att titta på andra lager i OSI-modellen. Det är enkelt att fokusera på nätverket och lagren 1–3 (fysisk, data och nätverk), men problemet kan vara på Layer 7 i programlagret. Ha ett öppet sinne och verifiera antaganden.

Kommentar

Geografisk svarstid mellan slutpunkter är den största komponenten i svarstiden. Utrustningsfördröjning som till exempel har fysiska och virtuella komponenter och antal hopp är inblandade. Men geografin har visat sig ha större inverkan på den övergripande svarstiden vid hantering av WAN-anslutningar. Kom ihåg att avståndet för fiberkörningen inte är det raka eller färdplansavståndet. Använd en stadsdistanskalkylator som, även om den är felaktig, är tillräckligt bra.