Weryfikowanie połączenia usługi ExpressRoute
Ten artykuł ułatwia weryfikowanie i rozwiązywanie problemów z łącznością usługi Azure ExpressRoute. Usługa ExpressRoute rozszerza sieć lokalną do chmury firmy Microsoft za pośrednictwem połączenia prywatnego obsługiwanego przez dostawcę łączności. Łączność usługi ExpressRoute obejmuje trzy odrębne strefy sieciowe:
- Sieć klienta
- Sieć dostawcy
- Centrum danych firmy Microsoft
Uwaga
W modelu łączności ExpressRoute Direct można bezpośrednio nawiązać połączenie z portem routerów usługi Microsoft Enterprise Edge (MSEE). Ten model obejmuje tylko sieć i strefy sieciowe firmy Microsoft.
Ten artykuł pomaga zidentyfikować problemy z łącznością i uzyskać pomoc techniczną od odpowiedniego zespołu, aby je rozwiązać.
Ważne
Ten artykuł ma pomóc w diagnozowaniu i rozwiązywaniu prostych problemów. Nie jest to zamiennik pomocy technicznej firmy Microsoft. Jeśli nie możesz rozwiązać problemu, korzystając z tych wskazówek, otwórz bilet pomocy technicznej z pomoc techniczna firmy Microsoft.
Omówienie
Na poniższym diagramie przedstawiono logiczną łączność sieci klienta z siecią firmy Microsoft za pośrednictwem usługi ExpressRoute.
Na diagramie liczby wskazują kluczowe punkty sieciowe:
- Urządzenie obliczeniowe klienta (na przykład serwer lub komputer).
- Routery brzegowe klienta (CE).
- Routery/przełączniki brzegowe dostawcy (PE) połączone z routerami brzegowymi klientów.
- Routery usługi ExpressRoute w przeglądarce Microsoft Enterprise Edge (MSEE) o nazwie PE-MSEEs.
- MSEEs.
- Brama sieci wirtualnej.
- Urządzenie obliczeniowe w sieci wirtualnej platformy Azure.
Do tych punktów sieciowych odwołuje się ich numer skojarzony w całym artykule.
W zależności od modelu łączności usługi ExpressRoute punkty sieciowe 3 i 4 mogą być przełącznikami (urządzenia warstwy 2) lub routerami (urządzenia warstwy 3). Modele łączności to kolokacja wymiany chmury, połączenie Ethernet typu punkt-punkt lub dowolny-dowolny (IPVPN).
W modelu łączności bezpośredniej nie ma punktów sieciowych 3 i 4. Zamiast tego urzędy certyfikacji (2) są bezpośrednio połączone z sieciami MSEE za pośrednictwem ciemnego włókna.
Jeśli używany jest model kolokacji wymiany chmury, ethernet typu punkt-punkt lub bezpośredni, urzędy certyfikacji (2) ustanawiają komunikację równorzędną protokołu BGP (Border Gateway Protocol) z połączeniami MSEEs (5).
Jeśli jest używany model łączności typu dowolny-dowolny (IPVPN), pe-MSEEs (4) ustanawia komunikację równorzędną BGP z protokołami MSEE (5). PE-MSEEs propagują trasy odebrane od firmy Microsoft z powrotem do sieci klienta za pośrednictwem sieci dostawcy usług IPVPN.
Uwaga
W celu zapewnienia wysokiej dostępności firma Microsoft ustanawia w pełni nadmiarową łączność równoległą między parami MSEE i PE-MSEE. W pełni nadmiarowa równoległa ścieżka sieciowa jest również zachęcana między siecią klienta a parami PE/CE. Aby uzyskać więcej informacji na temat wysokiej dostępności, zobacz Projektowanie pod kątem wysokiej dostępności za pomocą usługi ExpressRoute.
W poniższych sekcjach przedstawiono kroki logiczne rozwiązywania problemów z obwodem usługi ExpressRoute.
Weryfikowanie aprowizacji i stanu obwodu
Aprowizowanie obwodu usługi ExpressRoute ustanawia nadmiarowe połączenie warstwy 2 między CEs/PE-MSEEs (2/4) i MSEEs (5). Aby uzyskać więcej informacji na temat tworzenia, modyfikowania, aprowizacji i weryfikowania obwodu usługi ExpressRoute, zobacz Tworzenie i modyfikowanie obwodu usługi ExpressRoute.
Napiwek
Klucz usługi jednoznacznie identyfikuje obwód usługi ExpressRoute. Jeśli potrzebujesz pomocy od firmy Microsoft lub partnera usługi ExpressRoute, aby rozwiązać problem, podaj klucz usługi, aby łatwo zidentyfikować obwód.
Weryfikacja za pośrednictwem witryny Azure Portal
W witrynie Azure Portal przejdź do strony obwodu usługi ExpressRoute. Sekcja 
strony zawiera listę podstawowych elementów usługi ExpressRoute, jak pokazano na poniższym zrzucie ekranu:
W podstawowych elementach usługi ExpressRoute stan obwodu wskazuje stan obwodu po stronie firmy Microsoft, a stan dostawcy wskazuje, czy obwód został aprowizowany przez dostawcę usług.
Aby obwód usługi ExpressRoute działał, stan obwodu musi być Włączony, a stan dostawcy musi być Aprowizowany.
Uwaga
Jeśli stan obwodu jest zablokowany w pozycji Nie włączono, skontaktuj się z pomoc techniczna firmy Microsoft. Jeśli stan dostawcy jest zablokowany w obszarze Nie aprowizowana, skontaktuj się z dostawcą usług.
Weryfikacja za pomocą programu PowerShell
Aby wyświetlić listę wszystkich obwodów usługi ExpressRoute w grupie zasobów, użyj następującego polecenia:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
Napiwek
Aby znaleźć nazwę grupy zasobów, użyj Get-AzResourceGroup polecenia , aby wyświetlić listę wszystkich grup zasobów w ramach subskrypcji.
Aby uzyskać szczegółowe informacje o określonym obwodzie usługi ExpressRoute w grupie zasobów, użyj następującego polecenia:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Oto przykładowa odpowiedź:
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 : []
Aby upewnić się, że obwód usługi ExpressRoute działa, upewnij się, że następujące pola są ustawione poprawnie:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Uwaga
Jeśli stan obwodu jest zablokowany w pozycji Nie włączono, skontaktuj się z pomoc techniczna firmy Microsoft. Jeśli stan dostawcy jest zablokowany w obszarze Nie aprowizowana, skontaktuj się z dostawcą usług.
Walidacja konfiguracji komunikacji równorzędnej
Po aprowizacji obwodu usługi ExpressRoute przez dostawcę usług można utworzyć wiele konfiguracji routingu przy użyciu zewnętrznego protokołu BGP (eBGP) za pośrednictwem obwodu między urzędami CEs/MSEE-PEs (2/4) i msEEs (5). Każdy obwód usługi ExpressRoute może mieć jedną lub obie następujące konfiguracje komunikacji równorzędnej:
- Prywatna komunikacja równorzędna platformy Azure: dla ruchu do prywatnych sieci wirtualnych na platformie Azure
- Komunikacja równorzędna firmy Microsoft: w przypadku ruchu do publicznych punktów końcowych platformy jako usługi (PaaS) i oprogramowania jako usługi (SaaS)
Aby uzyskać więcej informacji na temat tworzenia i modyfikowania konfiguracji routingu, zobacz Tworzenie i modyfikowanie routingu dla obwodu usługi ExpressRoute.
Weryfikacja za pośrednictwem witryny Azure Portal
Uwaga
W modelu łączności IPVPN dostawcy usług obsługują odpowiedzialność za konfigurowanie komunikacji równorzędnej (usługi warstwy 3). Jeśli komunikacja równorzędna jest pusta w portalu po skonfigurowaniu go przez dostawcę usług, spróbuj odświeżyć konfigurację obwodu przy użyciu przycisku odświeżania w portalu. Ta operacja spowoduje ściągnięcie bieżącej konfiguracji routingu z obwodu.
W witrynie Azure Portal możesz sprawdzić stan obwodu usługi ExpressRoute na swojej stronie. Sekcja zawiera listę komunikacji równorzędnej usługi ExpressRoute, jak pokazano na poniższym zrzucie ekranu:
W poprzednim przykładzie aprowizowana jest prywatna komunikacja równorzędna platformy Azure, ale publiczne komunikacje równorzędne platformy Azure i komunikacja równorzędna firmy Microsoft nie są. Pomyślnie zainicjowany kontekst komunikacji równorzędnej będzie również zawierać listę podsieci podstawowych i pomocniczych podsieci punkt-punkt. Podsieci /30 są używane dla adresów IP interfejsu MSEE i CEs/PE-MSEEs. Lista wskazuje również, kto ostatnio zmodyfikował konfigurację.
Uwaga
Jeśli włączenie komunikacji równorzędnej nie powiedzie się, sprawdź, czy przypisane podsieci podstawowe i pomocnicze są zgodne z konfiguracją połączonego urządzenia CE/PE-MSEE. Sprawdź również, czy VlanIdwartości , AzureASNi PeerASN w msEEs są zgodne z wartościami połączonych CE/PE-MSEE.
Jeśli wybrano skrót MD5, upewnij się, że klucz współużytkowany jest taki sam zarówno w parach MSEE, jak i CE/PE-MSEE. Wcześniej skonfigurowane klucze udostępnione nie będą wyświetlane ze względów bezpieczeństwa.
Jeśli musisz zmienić dowolną z tych konfiguracji na routerze MSEE, zobacz Tworzenie i modyfikowanie routingu dla obwodu usługi ExpressRoute.
Uwaga
W podsieci /30 przypisanej dla interfejsu firma Microsoft użyje drugiego użytecznego adresu IP dla interfejsu MSEE. Upewnij się, że pierwszy adres IP do użytku jest przypisany do równorzędnego ce/PE-MSEE.
Weryfikacja za pomocą programu PowerShell
Aby uzyskać szczegółowe informacje o konfiguracji prywatnej komunikacji równorzędnej platformy Azure, użyj następujących poleceń:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
Oto przykładowa odpowiedź na pomyślnie skonfigurowaną prywatną komunikację równorzędną:
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
Pomyślnie włączony kontekst komunikacji równorzędnej zawiera prefiksy adresów podstawowych i pomocniczych. Podsieci /30 są używane dla adresów IP interfejsu MSEE i CEs/PE-MSEEs.
Aby uzyskać szczegółowe informacje o konfiguracji komunikacji równorzędnej firmy Microsoft, użyj następujących poleceń:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt
Jeśli komunikacja równorzędna nie jest skonfigurowana, zostanie wyświetlony komunikat o błędzie. Oto przykładowa odpowiedź, gdy określona komunikacja równorzędna nie jest skonfigurowana w obwodzie:
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
Uwaga
Jeśli włączenie komunikacji równorzędnej nie powiedzie się, sprawdź, czy przypisane podsieci podstawowe i pomocnicze są zgodne z konfiguracją połączonego urządzenia CE/PE-MSEE. Sprawdź również, czy VlanIdwartości , AzureASNi PeerASN w msEEs są zgodne z wartościami połączonych CE/PE-MSEE.
Jeśli wybrano skrót MD5, upewnij się, że klucz współużytkowany jest taki sam zarówno w parach MSEE, jak i CE/PE-MSEE. Wcześniej skonfigurowane klucze udostępnione nie będą wyświetlane ze względów bezpieczeństwa.
Jeśli musisz zmienić dowolną z tych konfiguracji na routerze MSEE, zobacz Tworzenie i modyfikowanie routingu dla obwodu usługi ExpressRoute.
Uwaga
W podsieci /30 przypisanej dla interfejsu firma Microsoft użyje drugiego użytecznego adresu IP dla interfejsu MSEE. Upewnij się, że pierwszy adres IP do użytku jest przypisany do równorzędnego ce/PE-MSEE.
Weryfikowanie protokołu ARP
Tabela ARP (Address Resolution Protocol) zawiera mapowanie adresu IP i adresu MAC dla określonej komunikacji równorzędnej. Tabela ARP dla komunikacji równorzędnej obwodu usługi ExpressRoute zawiera następujące informacje dotyczące każdego interfejsu (podstawowego i pomocniczego):
- Mapowanie adresu IP dla interfejsu routera lokalnego na adres MAC
- Mapowanie adresu IP dla interfejsu routera ExpressRoute na adres MAC (opcjonalnie)
- Wiek mapowania
Tabele protokołu ARP mogą ułatwić walidację konfiguracji warstwy 2 oraz rozwiązywanie podstawowych problemów z łącznością warstwy 2.
Uwaga
W zależności od platformy sprzętowej wyniki protokołu ARP mogą się różnić i wyświetlać tylko interfejs lokalny .
Aby dowiedzieć się, jak wyświetlić tabelę ARP komunikacji równorzędnej usługi ExpressRoute i jak używać informacji do rozwiązywania problemów z łącznością w warstwie 2, zobacz Uzyskiwanie tabel ARP w modelu wdrażania usługi Resource Manager.
Weryfikowanie protokołu BGP i tras na urządzeniu MSEE
Aby pobrać tabelę routingu z rozwiązania MSEE w ścieżce podstawowej dla kontekstu routingu prywatnego, użyj następującego polecenia:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName <CircuitName> -PeeringType AzurePrivatePeering -ResourceGroupName <ResourceGroupName>
Przykładowa odpowiedź:
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##
Uwaga
Jeśli stan komunikacji równorzędnej eBGP między urządzeniami MSEE i CE/PE-MSEE jest aktywny lub bezczynny, sprawdź, czy podsieci podstawowej i pomocniczej komunikacji równorzędnej są zgodne z konfiguracją połączonego urządzenia CE/PE-MSEE. VlanIdUpewnij się, że wartości , AzureASNi są PeerASN poprawne w msEE i pasują do tych w połączonym ce/PE-MSEE. Jeśli jest używane skróty MD5, klucz współużytkowany musi być taki sam zarówno w parach MSEE, jak i CE/PE-MSEE. Aby uzyskać informacje na temat zmian konfiguracji routera MSEE, zobacz Tworzenie i modyfikowanie routingu dla obwodu usługi ExpressRoute.
Uwaga
Jeśli niektóre miejsca docelowe nie są osiągalne za pośrednictwem komunikacji równorzędnej, sprawdź tabelę tras MSEE dla odpowiedniego kontekstu komunikacji równorzędnej. Jeśli istnieje pasujący prefiks, upewnij się, że żadne zapory, sieciowe grupy zabezpieczeń lub listy ACL nie blokują ruchu.
Przykładowa odpowiedź na nieistniejącą komunikację równorzędną:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Potwierdzanie przepływu ruchu
Aby uzyskać statystyki ruchu (bajty w i na wyjęcie) dla kontekstu komunikacji równorzędnej, użyj następującego polecenia:
Get-AzExpressRouteCircuitStats -ResourceGroupName <ResourceGroupName> -ExpressRouteCircuitName <CircuitName> -PeeringType 'AzurePrivatePeering'
Przykładowe wyjście:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Przykładowe dane wyjściowe dla nieistniejącej komunikacji równorzędnej:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Testowanie łączności prywatnej komunikacji równorzędnej
Przetestuj łączność prywatnej komunikacji równorzędnej, licząc pakiety przychodzące i opuszczając brzeg firmy Microsoft obwodu usługi ExpressRoute na urządzeniach MSEE. To narzędzie diagnostyczne używa listy ACL do zliczania pakietów, które napotykają określone reguły, potwierdzając łączność.
Uruchamianie testu
W witrynie Azure Portal wybierz pozycję Diagnozowanie i rozwiązywanie problemów z obwodem usługi ExpressRoute.
Wybierz pozycję Problemy z łącznością i wydajnością.
Na liście rozwijanej Poinformuj nas więcej o problemie wybierz pozycję Problemy z prywatną komunikacją równorzędną.
Rozwiń sekcję Testowanie łączności prywatnej komunikacji równorzędnej.
Uruchom test PsPing z lokalnego adresu IP do adresu IP platformy Azure i zachowaj jego działanie podczas testu.
Wypełnij pola formularza tymi samymi adresami IP używanymi w kroku 5, a następnie wybierz pozycję Prześlij i poczekaj na wyniki.
Interpretowanie wyników
Przejrzyj wyniki dla podstawowych i pomocniczych urządzeń MSEE:
Dopasowania wysyłane i odbierane dla obu środowisk MSEE: wskazuje na ruch przychodzący i wychodzący w dobrej kondycji. Wszelkie straty są podrzędne z msEEs.
Odebrane dopasowania, ale nie są wysyłane: ruch dociera do platformy Azure, ale nie zwraca. Sprawdź problemy z routingiem ścieżki powrotnej.
Wysłane dopasowania, ale nie odebrane dopasowania: ruch dociera do środowiska lokalnego, ale nie wraca do platformy Azure. Skontaktuj się z dostawcą, aby rozwiązać ten problem.
Jedno urządzenie MSEE nie pokazuje dopasowań, a drugi pokazuje dobre dopasowania: wskazuje, że jedno urządzenie MSEE nie odbiera ani nie przekazuje ruchu. Może to być offline.
Jeśli testujesz narzędzie PsPing ze środowiska lokalnego do platformy Azure, odebrane wyniki pokazują dopasowania, ale wysłane wyniki nie pokazują dopasowań: ten wynik wskazuje, że ruch jest przesyłany na platformę Azure, ale nie wraca do środowiska lokalnego. Sprawdź, czy nie występują problemy z routingiem ścieżki powrotnej. Czy na przykład reklamujesz odpowiednie prefiksy na platformie Azure? Czy trasa zdefiniowana przez użytkownika (UDR) zastępuje prefiksy?
Jeśli testujesz narzędzie PsPing z platformy Azure do środowiska lokalnego, wysłane wyniki pokazują dopasowania, ale otrzymane wyniki nie pokazują dopasowań: ten wynik wskazuje, że ruch jest przesyłany do środowiska lokalnego, ale nie wraca do platformy Azure. Skontaktuj się z dostawcą, aby dowiedzieć się, dlaczego ruch nie jest kierowany na platformę Azure za pośrednictwem obwodu usługi ExpressRoute.
Jedno urządzenie MSEE nie pokazuje dopasowań, ale drugie pokazuje dobre dopasowania: ten wynik wskazuje, że jedno urządzenie MSEE nie odbiera ani nie przekazuje żadnego ruchu. Może być w trybie offline (na przykład protokół BGP/ARP nie działa).
- Możesz uruchomić dodatkowe testy, aby potwierdzić złą ścieżkę, reklamując unikatową trasę lokalną /32 w sesji protokołu BGP na tej ścieżce.
- Uruchom polecenie "Przetestuj prywatną łączność komunikacji równorzędnej" przy użyciu unikatowego /32 anonsowanego jako lokalnego adresu docelowego i przejrzyj wyniki, aby potwierdzić kondycję ścieżki.
Wyniki testu dla każdego urządzenia MSEE wyglądają jak w poniższym przykładzie:
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
Weryfikowanie dostępności bramy sieci wirtualnej
Brama sieci wirtualnej usługi ExpressRoute zarządza łącznością z usługami łącza prywatnego i prywatnymi adresami IP w sieci wirtualnej platformy Azure. Firma Microsoft zarządza tą infrastrukturą i może wykonywać konserwację, zmniejszając wydajność.
Aby rozwiązać problemy z łącznością i sprawdzić dostępność najnowszej konserwacji:
W witrynie Azure Portal wybierz pozycję Diagnozowanie i rozwiązywanie problemów z obwodem usługi ExpressRoute.
Wybierz pozycję Problemy z wydajnością.
Poczekaj na uruchomienie diagnostyki i zinterpretuj wyniki.
Jeśli wystąpiła konserwacja podczas utraty lub opóźnienia pakietów, może to mieć wpływ na problemy z łącznością. Wykonaj zalecane kroki i rozważ uaktualnienie jednostki SKU bramy sieci wirtualnej, aby zapewnić większą przepływność i uniknąć przyszłych problemów.
Następne kroki
Aby uzyskać więcej informacji lub pomocy, zapoznaj się z następującymi linkami: