Ověření připojení ExpressRoute
Tento článek vám pomůže ověřit a vyřešit potíže s připojením k Azure ExpressRoute. ExpressRoute rozšiřuje místní síť do cloudu Microsoftu přes privátní připojení, které poskytovatel připojení usnadňuje. Připojení ExpressRoute zahrnuje tři různé síťové zóny:
- Síť zákazníků
- Síť zprostředkovatele
- Datacentrum Microsoftu
Poznámka:
V modelu připojení ExpressRoute Direct se můžete přímo připojit k portu směrovačů Microsoft Enterprise Edge (MSEE). Tento model zahrnuje pouze vaši síť a zóny sítě Microsoftu.
Tento článek vám pomůže identifikovat problémy s připojením a vyhledat podporu od příslušného týmu, aby je vyřešil.
Důležité
Tento článek vám pomůže s diagnostikou a řešením jednoduchých problémů. Nejedná se o náhradu za podporu Microsoftu. Pokud nemůžete problém vyřešit pomocí těchto doprovodných materiálů, otevřete lístek podpory s podpora Microsoftu.
Přehled
Následující diagram znázorňuje logické připojení sítě zákazníka k síti Microsoftu prostřednictvím ExpressRoute.
Čísla v diagramu označují klíčové síťové body:
- Zákaznické výpočetní zařízení (například server nebo počítač).
- Hraniční směrovače zákazníka (CE).
- Hraniční směrovače nebo přepínače poskytovatele (PE) směřující k hraničním směrovačům zákazníka.
- PEs směřující ke směrovačům Microsoft Enterprise Edge ExpressRoute (MSEEs) označovaným jako PE-MSEEs.
- MsEEs.
- Brána virtuální sítě:
- Výpočetní zařízení ve virtuální síti Azure
Na tyto síťové body se odkazuje jejich přidruženým číslem v celém článku.
Síťové body 3 a 4 mohou být v závislosti na modelu připojení ExpressRoute přepínače (zařízení vrstvy 2) nebo směrovače (zařízení vrstvy 3). Modely připojení jsou kolokace cloudové výměny, ethernetové připojení typu point-to-point nebo any-to-any (IPVPN).
V přímém modelu připojení nejsou žádné síťové body 3 a 4. Místo toho jsou CE (2) přímo připojeny k prostředí MSEE využitím nenasvícených vláken.
V případě použití kolokace výměny cloudu, ethernetu typu point-to-point nebo přímého modelu připojení, CE (2) vytvoří partnerský vztah protokolu BGP (Border Gateway Protocol) s msEEs (5).
V případě použití modelu propojení typu any-to-any (IPVPN) PE-MSEEs (4) navážou partnerský vztah protokolu BGP s prostředím MSEEs (5). Prostředí PE-MSEEs šíří trasy přijaté z Microsoftu zpět do sítě zákazníka prostřednictvím sítě poskytovatele služeb IPVPN.
Poznámka:
Pro zajištění vysoké dostupnosti Microsoft vytvoří plně redundantní paralelní připojení mezi páry MSEE a PE-MSEE. Mezi páry sítě zákazníka a PE/CE se také doporučuje plně redundantní paralelní síťová cesta. Další informace o vysoké dostupnosti najdete v tématu Návrh pro zajištění vysoké dostupnosti pomocí ExpressRoute.
Následující části představují logické kroky při řešení potíží s okruhem ExpressRoute.
Ověření zřizování a stavu okruhu
Zřízení okruhu ExpressRoute vytvoří redundantní připojení vrstvy 2 mezi prostředími CEs/PE-MSEEs (2/4) a rozhraními MSEEs (5). Další informace o vytváření, úpravách, zřizování a ověřování okruhu ExpressRoute najdete v tématu Vytvoření a úprava okruhu ExpressRoute.
Tip
Klíč služby jednoznačně identifikuje okruh ExpressRoute. Pokud potřebujete pomoc od Microsoftu nebo partnera ExpressRoute k řešení problému, zadejte klíč služby, abyste okruh snadno identifikovali.
Ověření prostřednictvím webu Azure Portal
Na webu Azure Portal přejděte na stránku okruhu ExpressRoute. Část 
stránky obsahuje základní informace o ExpressRoute, jak je znázorněno na následujícím snímku obrazovky:
V základních informacích ExpressRoute stav okruhu označuje stav okruhu na straně Microsoftu a stav poskytovatele označuje, jestli byl okruh zřízen poskytovatelem služeb.
Aby byl okruh ExpressRoute funkční, musí být stav okruhu zapnuto a stav poskytovatele musí být zřízený.
Poznámka:
Pokud je stav okruhu zablokovaný v nezablokované, obraťte se na podpora Microsoftu. Pokud je stav poskytovatele zablokovaný v nezařizovaném stavu, obraťte se na svého poskytovatele služeb.
Ověření pomocí PowerShellu
Pokud chcete zobrazit seznam všech okruhů ExpressRoute ve skupině prostředků, použijte následující příkaz:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
Tip
Pokud chcete najít název skupiny prostředků, použijte Get-AzResourceGroup příkaz k výpisu všech skupin prostředků ve vašem předplatném.
Pokud chcete získat podrobnosti o konkrétním okruhu ExpressRoute ve skupině prostředků, použijte následující příkaz:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Zde je příklad odpovědi:
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 : []
Pokud chcete ověřit, že je okruh ExpressRoute funkční, ujistěte se, že jsou správně nastavená následující pole:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Poznámka:
Pokud je stav okruhu zablokovaný v nezablokované, obraťte se na podpora Microsoftu. Pokud je stav poskytovatele zablokovaný v nezařizovaném stavu, obraťte se na svého poskytovatele služeb.
Ověřte konfiguraci peeringu
Jakmile poskytovatel služeb zřídí okruh ExpressRoute, můžete vytvořit více konfigurací směrování pomocí externího protokolu BGP (eBGP) přes okruh mezi CEs/MSEE-PEs (2/4) a prostředími MSEEs (5). Každý okruh ExpressRoute může mít jednu nebo obě následující konfigurace partnerského vztahu:
- Privátní partnerský vztah Azure: Přenos do privátních virtuálních sítí v Azure
- Partnerský vztah Microsoftu: Přenos do veřejných koncových bodů platformy jako služby (PaaS) a softwaru jako služby (SaaS)
Další informace o vytváření a úpravách konfigurací směrování najdete v tématu Vytvoření a úprava směrování pro okruh ExpressRoute.
Ověření prostřednictvím webu Azure Portal
Poznámka:
V modelu připojení IPVPN poskytovatelé služeb zpracovávají odpovědnost za konfiguraci partnerských vztahů (služby vrstvy 3). Pokud je partnerský vztah na portálu po nakonfigurování poskytovatelem služeb prázdný, zkuste aktualizovat konfiguraci okruhu pomocí tlačítka aktualizovat na portálu. Tato operace stáhne aktuální konfiguraci směrování z vašeho okruhu.
Na webu Azure Portal můžete zkontrolovat stav okruhu ExpressRoute na jeho stránce. Oddíl obsahuje seznam partnerských vztahů ExpressRoute, jak je znázorněno na následujícím snímku obrazovky:
V předchozím příkladu je privátní partnerský vztah Azure zřízený, ale veřejné partnerské vztahy Azure a partnerské vztahy Microsoftu nejsou. Úspěšně zřízený kontext partnerského vztahu také zobrazí seznam primárních a sekundárních podsítí typu point-to-point. Podsítě /30 se používají pro IP adresy rozhraní prostředí prostředí MSEEs a CEs/PE-MSEEs. Výpis také označuje, kdo konfiguraci naposledy upravil.
Poznámka:
Pokud povolení partnerského vztahu selže, zkontrolujte, jestli přiřazené primární a sekundární podsítě odpovídají konfiguraci propojené CE/PE-MSEE. Také ověřte, že VlanIdAzureASNhodnoty a hodnoty PeerASN v prostředí MSEE odpovídají hodnotám v propojeném prostředí CE/PE-MSEE.
Pokud je zvoleno hashování MD5, ujistěte se, že sdílený klíč je stejný u dvojic MSEE i CE/PE-MSEE. Dříve nakonfigurované sdílené klíče se z bezpečnostních důvodů nezobrazí.
Pokud potřebujete změnit některou z těchto konfigurací na směrovači MSEE, přečtěte si téma Vytvoření a úprava směrování pro okruh ExpressRoute.
Poznámka:
V podsíti /30 přiřazené pro rozhraní použije Microsoft druhou použitelnou IP adresu pro rozhraní MSEE. Ujistěte se, že je první použitelná IP adresa přiřazená partnerskému vztahu CE/PE-MSEE.
Ověření pomocí PowerShellu
Pokud chcete získat podrobnosti o konfiguraci privátního partnerského vztahu Azure, použijte následující příkazy:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
Tady je příklad odpovědi pro úspěšně nakonfigurovaný privátní partnerský vztah:
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
Kontext partnerského vztahu s úspěšně povoleným seznamem předpon primární a sekundární adresy. Podsítě /30 se používají pro IP adresy rozhraní prostředí prostředí MSEEs a CEs/PE-MSEEs.
Pokud chcete získat podrobnosti o konfiguraci partnerského vztahu Microsoftu, použijte následující příkazy:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt
Pokud partnerský vztah není nakonfigurovaný, zobrazí se chybová zpráva. Tady je příklad odpovědi, když není v okruhu nakonfigurovaný stavový partnerský vztah:
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
Poznámka:
Pokud povolení partnerského vztahu selže, zkontrolujte, jestli přiřazené primární a sekundární podsítě odpovídají konfiguraci propojené CE/PE-MSEE. Také ověřte, že VlanIdAzureASNhodnoty a hodnoty PeerASN v prostředí MSEE odpovídají hodnotám v propojeném prostředí CE/PE-MSEE.
Pokud je zvoleno hashování MD5, ujistěte se, že sdílený klíč je stejný u dvojic MSEE i CE/PE-MSEE. Dříve nakonfigurované sdílené klíče se z bezpečnostních důvodů nezobrazí.
Pokud potřebujete změnit některou z těchto konfigurací na směrovači MSEE, přečtěte si téma Vytvoření a úprava směrování pro okruh ExpressRoute.
Poznámka:
V podsíti /30 přiřazené pro rozhraní použije Microsoft druhou použitelnou IP adresu pro rozhraní MSEE. Ujistěte se, že je první použitelná IP adresa přiřazená partnerskému vztahu CE/PE-MSEE.
Ověření protokolu ARP
Tabulka protokolu ARP (Address Resolution Protocol) zajišťuje mapování IP adresy a MAC adresy pro konkrétní partnerský vztah. Tabulka protokolu ARP pro partnerský vztah okruhu ExpressRoute poskytuje pro každé rozhraní následující informace (primární a sekundární):
- Mapování IP adresy místního rozhraní směrovače na MAC adresu
- Mapování IP adresy místního rozhraní směrovače ExpressRoute na MAC adresu (volitelné)
- Doba trvání mapování
Tabulky protokolu ARP můžou pomoct ověřit konfiguraci vrstvy 2 a odstranit základní problémy s připojením vrstvy 2.
Poznámka:
V závislosti na hardwarové platformě se výsledky protokolu ARP mohou lišit a zobrazit pouze místní rozhraní.
Informace o tom, jak zobrazit tabulku protokolu ARP partnerského vztahu ExpressRoute a jak používat informace k řešení potíží s připojením vrstvy 2, najdete v tématu Získání tabulek protokolu ARP v modelu nasazení Resource Manager.
Ověření protokolu BGP a tras v MSEE
Pokud chcete načíst směrovací tabulku z MSEE na primární cestě pro kontext privátního směrování, použijte následující příkaz:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName <CircuitName> -PeeringType AzurePrivatePeering -ResourceGroupName <ResourceGroupName>
Příklad odpovědi:
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##
Poznámka:
Pokud je stav partnerského vztahu eBGP mezi MSEE a CE/PE-MSEE aktivní nebo nečinný, ověřte, že primární a sekundární partnerské podsítě odpovídají konfiguraci propojené CE/PE-MSEE. VlanIdUjistěte se, AzureASNže v prostředí MSEE jsou správné hodnoty a PeerASN odpovídají hodnotám v propojeném prostředí CE/PE-MSEE. Pokud se použije hashování MD5, sdílený klíč musí být stejný u dvojic MSEE i CE/PE-MSEE. Změny konfigurace ve směrovači MSEE najdete v tématu Vytvoření a úprava směrování pro okruh ExpressRoute.
Poznámka:
Pokud jsou určité cíle nedostupné přes partnerský vztah, zkontrolujte směrovací tabulku MSEE pro odpovídající kontext partnerského vztahu. Pokud existuje odpovídající předpona, ujistěte se, že provoz neblokují žádné brány firewall, skupiny zabezpečení sítě ani seznamy ACL.
Příklad odpovědi pro neexistující partnerský vztah:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Potvrzení toku provozu
Pokud chcete získat statistiky provozu (bajty in a out) pro kontext partnerského vztahu, použijte následující příkaz:
Get-AzExpressRouteCircuitStats -ResourceGroupName <ResourceGroupName> -ExpressRouteCircuitName <CircuitName> -PeeringType 'AzurePrivatePeering'
Příklad výstupu:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Příklad výstupu pro neexistující partnerský vztah:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Testování připojení privátních partnerských vztahů
Otestujte připojení privátního partnerského vztahu počítáním paketů přicházejících do okruhu ExpressRoute a opuštěním hraničního zařízení ExpressRoute na zařízeních MSEE. Tento diagnostický nástroj používá seznam ACL ke spočítání paketů, které dorazí na konkrétní pravidla a potvrdí připojení.
Spuštění testu
Na webu Azure Portal vyberte Diagnostikovat a řešit problémy z okruhu ExpressRoute.
Vyberte Problémy s připojením a výkonem.
V rozevíracím seznamu Řekněte nám o problému, který máte , vyberte Problémy se soukromým partnerským vztahem.
Rozbalte část Test připojení privátního partnerského vztahu.
Spusťte test PsPing z místní IP adresy na ip adresu Azure a během testu ho nechte spuštěný.
Vyplňte pole formuláře stejnými IP adresami, které jste použili v kroku 5, a pak vyberte Odeslat a počkejte na výsledky.
Interpretace výsledků
Zkontrolujte výsledky primárních a sekundárních zařízení MSEE:
Odpovídá odeslané a přijaté v obou modelech MSEEs: Označuje příchozí i odchozí provoz v pořádku. Jakákoli ztráta je z prostředí MSEE podřízená.
Přijaté shody, ale neodeslaná shoda: Provoz se blíží Do Azure, ale nevrací se. Zkontrolujte problémy se směrováním zpáteční cesty.
Odeslané shody, ale žádné přijaté shody: Provoz se blíží místně, ale nevrátí se do Azure. Obraťte se na svého poskytovatele a vyřešte problém.
Jedna MSEE nezobrazuje žádné shody, druhá zobrazuje dobré shody: Označuje, že jeden MSEE nepřijímá nebo předává provoz. Může být offline.
Pokud testujete PsPing z místního prostředí do Azure, zobrazují se odpovídající výsledky, ale odeslané výsledky nezobrazují žádné shody: Tento výsledek indikuje, že provoz přichází do Azure, ale nevrací se do místního prostředí. Zkontrolujte problémy se směrováním zpětné cesty. Oznamujete například příslušné předpony do Azure? Přepisuje uživatelem definovaná trasa (UDR) předpony?
Pokud testujete PsPing z Azure do místního prostředí, zobrazují se odpovídající výsledky, ale přijaté výsledky nezobrazují žádné shody: Tento výsledek indikuje, že provoz přichází do místního prostředí, ale nevrací se do Azure. Spolu s vaším poskytovatelem zjistěte, proč se provoz nesměruje do Azure přes okruh ExpressRoute.
Jedno prostředí zařízení MSEE nezobrazuje žádné shody, ale druhé ukazuje odpovídající shody: Tento výsledek indikuje, že jedno zařízení MSEE nepřijímá ani nepředává žádný provoz. Může být ve stavu „offline” (například BGP/ARP je mimo provoz).
- Můžete provést další testování, abyste potvrdili, že cesta není v pořádku, a to oznamováním jedinečné místní trasy /32 přes relaci protokolu BGP na této cestě.
- Spusťte test připojení privátního partnerského vztahu pomocí jedinečné adresy /32 inzerované jako místní cílové adresy a zkontrolujte výsledky a ověřte stav cesty.
Výsledky testů pro každé zařízení MSEE vypadají jako v následujícím příkladu:
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
Ověření dostupnosti brány virtuální sítě
Brána virtuální sítě ExpressRoute spravuje připojení ke službám privátního propojení a privátním IP adresám ve virtuální síti Azure. Microsoft tuto infrastrukturu spravuje a může provádět údržbu, což snižuje výkon.
Řešení potíží s připojením a kontrola nedávné údržby:
Na webu Azure Portal vyberte Diagnostikovat a řešit problémy z okruhu ExpressRoute.
Vyberte Problémy s výkonem.
Počkejte na spuštění diagnostiky a interpretaci výsledků.
Pokud během ztráty nebo latence paketů došlo k údržbě, mohlo by to přispět k problémům s připojením. Postupujte podledoporučenýchchchch
Další kroky
Další informace nebo nápovědu najdete na následujících odkazech: