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é běžně usnadňuje poskytovatel připojení. Připojení ExpressRoute tradičně zahrnuje tři odlišné 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). Model přímého připojení zahrnuje pouze vaše a síťové zóny Microsoftu.
Tento článek vám pomůže zjistit, jestli a kde existuje problém s připojením. Pokud chcete tento problém vyřešit, můžete požádat o podporu příslušného týmu.
Důležité
Tento článek vám pomůže s diagnostikou a řešením jednoduchých problémů. Nemá být náhradou za podporu Microsoftu. Pokud nemůžete problém vyřešit pomocí pokynů v tomto článku, 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.
V předchozím diagramu čísla 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), které čelí hraničním směrovačům zákazníka.
- PEs, které čelí směrovačům Microsoft Enterprise Edge ExpressRoute (MSEE). Tento článek je nazývá PE-MSEEs.
- MsEEs.
- Brána virtuální sítě:
- Výpočetní zařízení ve virtuální síti Azure
Tento článek někdy odkazuje na tyto síťové body podle jejich přidruženého čísla.
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í ExpressRoute jsou kolokace s výměnou cloudu, ethernetové připojení typu point-to-point nebo propojení typu 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 článku 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 tom, jak vytvořit, upravit, zřídit a ověřit okruh ExpressRoute, najdete v článku 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í potíží s ExpressRoute, zadejte klíč služby, abyste okruh snadno identifikovali.
Ověření prostřednictvím webu Azure Portal
Na webu Azure Portal otevřete 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 části Základy ExpressRoute stav okruhu označuje stav okruhu na straně Microsoftu. Stav poskytovatele označuje, jestli je okruh zřízený nebo není zřízený na straně poskytovatele služeb.
Aby byl okruh ExpressRoute funkční, musí být stav okruhu zapnuto a stav poskytovatele musí být zřízený.
Poznámka:
Po nakonfigurování okruhu ExpressRoute, pokud je stav okruhu zablokovaný ve stavu Nepovoleno, kontaktujte podpora Microsoftu. Pokud je stav poskytovatele zablokovaný ve stavu Nezřizovací , 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 hledáte název skupiny prostředků, můžete ji získat pomocí Get-AzResourceGroup příkazu k výpisu všech skupin prostředků ve vašem předplatném.
Pokud chcete vybrat konkrétní okruh 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í, věnujte zvláštní pozornost následujícím polím:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Poznámka:
Po nakonfigurování okruhu ExpressRoute, pokud je stav okruhu zablokovaný ve stavu Nepovoleno, obraťte se na podpora Microsoftu. Pokud je stav poskytovatele zablokovaný ve stavu Nezřizované, obraťte se na svého poskytovatele služeb.
Ověřte konfiguraci peeringu
Po dokončení zřizování okruhu ExpressRoute je možné vytvořit několik konfigurací směrování založených na externím protokolu BGP (eBGP) přes okruh ExpressRoute mezi CEs/MSEE-PEs (2/4) a 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: Provoz do privátních virtuálních sítí v Azure
- Partnerský vztah Microsoftu: provoz do veřejných koncových bodů platformy jako služby (PaaS) a softwaru jako služby (SaaS)
Další informace o tom, jak vytvořit a upravit konfiguraci směrování, najdete v článku 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). V takovém modelu po nakonfigurování partnerského vztahu poskytovatelem služeb a pokud je partnerský vztah na portálu 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 stránce daného okruhu. V části stránky jsou uvedené partnerské vztahy 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 se nezřizují. Úspěšně zřízený kontext partnerského vztahu by měl také uvedené primární a sekundární podsítě typu point-to-point. Podsítě /30 se používají pro IP adresu rozhraní objektů MSEEs a CEEs/PE-MSEEs. U zřízených partnerských vztahů seznam 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. Zkontrolujte také, AzureASNjestli jsou v prostředí MSEEs použity správné VlanIdhodnoty a PeerASN jestli se tyto hodnoty mapují na hodnoty použité v propojeném prostředí CE/PE-MSEE.
Pokud zvolíte hashování MD5, sdílený klíč by měl být stejný u dvojic MSEE a 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í zvolí Microsoft druhou použitelnou IP adresu podsítě pro rozhraní MSEE. Proto se ujistěte, že první použitelná IP adresa podsítě byla přiřazena v partnerském 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
Úspěšně povolený kontext partnerského vztahu by měl uvedené předpony primární a sekundární adresy. Podsítě /30 se používají pro IP adresu rozhraní objektů MSEEs a CEEs/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. Zkontrolujte také, AzureASNjestli jsou v prostředí MSEEs použity správné VlanIdhodnoty a PeerASN jestli se tyto hodnoty mapují na hodnoty použité v propojeném prostředí CE/PE-MSEE.
Pokud zvolíte hashování MD5, sdílený klíč by měl být stejný u dvojic MSEE a 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í vybere Microsoft druhou použitelnou IP adresu podsítě pro rozhraní MSEE. Proto se ujistěte, že první použitelná IP adresa podsítě byla přiřazena v partnerském 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 získat 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 ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****
Zde je 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ý, zkontrolujte, jestli přiřazené primární a sekundární partnerské podsítě odpovídají konfiguraci propojeného CE/PE-MSEE. Zkontrolujte také, AzureASNjestli jsou v prostředí MSEEs použity správné VlanIdhodnoty a PeerASN jestli se tyto hodnoty mapují na hodnoty použité v propojeném prostředí CE/PE-MSEE. Pokud zvolíte hashování MD5, sdílený klíč by měl být stejný u dvojic MSEE a CE/PE-MSEE. 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:
Pokud některé cíle nejsou dosažitelné přes partnerský vztah, zkontrolujte směrovací tabulku prostředí MSEE odpovídajícího kontextu partnerského vztahu. Pokud ve směrovací tabulce existuje odpovídající předpona (může být IP adresa nated), zkontrolujte, jestli provoz neblokují nějaké brány firewall, skupiny zabezpečení sítě nebo seznamy řízení přístupu (ACL).
Následující příklad ukazuje odpověď příkazu pro partnerský vztah, který neexistuje:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
Potvrzení toku provozu
Pokud chcete získat kombinované statistiky provozu primární a sekundární cesty (bajty in a out) kontextu partnerského vztahu, použijte následující příkaz:
Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'
Tady je příklad výstupu příkazu:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Tady je příklad výstupu příkazu pro neexistující partnerský vztah:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* 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 a opuštěním hraničního zařízení Microsoftu okruhu ExpressRoute na zařízeních MSEE. Tento diagnostický nástroj funguje tak, že použije seznam ACL na zařízení MSEE za účelem spočítání počtu paketů, které dosáhly konkrétních pravidel seznamu ACL. Pomocí tohoto nástroje můžete ověřit připojení zodpovězením různých otázek:
- Dostávají se moje pakety do Azure?
- Vrací se do místního prostředí?
Spuštění testu
Pokud chcete získat přístup k diagnostickému nástroji, vyberte Diagnostikovat a řešit problémy z okruhu ExpressRoute na webu Azure Portal.
Vyberte problémy s Připojení ivity 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.
Posuňte se dolů do části Test připojení privátního partnerského vztahu a rozbalte ho.
Spusťte test PsPing z místní IP adresy na ip adresu Azure a během testu připojení ho nechte spuštěný.
Vyplňte pole formuláře. Musíte zadat stejné IP adresy pro místní prostředí a Azure, které jste použili v kroku 5. Pak vyberte Odeslat a počkejte, než se výsledky načtou.
Interpretace výsledků
Až budou výsledky připravené, máte dvě sady pro primární a sekundární zařízení MSEE. Zkontrolujte počet shod a odsud a k interpretaci výsledků použijte následující scénáře:
V obou zařízeních MSEE se zobrazí shody odeslaných a přijatých paketů: Tento výsledek ukazuje to, že je příchozí a odchozí provoz v prostředích zařízení MSEE ve vašem okruhu v pořádku. Pokud dochází ke ztrátě místně nebo v Azure, dochází k tomu u odchozího provozu ze zařízení MSEE.
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 „Testování připojení privátního partnerského vztahu (peering)” pomocí jedinečné adresy /32 oznamované 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
Tento výsledek testu má následující vlastnosti:
- Port IP adresy: 3389
- CIDR místní IP adresy: 10.0.0.0
- CIDR IP adresy Azure: 20.0.0.0
Ověření dostupnosti brány virtuální sítě
Brána virtuální sítě ExpressRoute usnadňuje připojení k službám privátního propojení a privátním IP adresám nasazeným do virtuální sítě Azure a rovině řízení. Microsoft spravuje infrastrukturu brány virtuální sítě a někdy prochází údržbou.
Během období údržby může dojít ke snížení výkonu brány virtuální sítě. Pokud chcete vyřešit potíže s připojením k virtuální síti a zjistit, jestli nedávná událost údržby způsobila snížení kapacity, postupujte takto:
Na webu Azure Portal vyberte Diagnostikovat a řešit problémy z okruhu ExpressRoute.
Vyberte možnost Problémy s výkonem.
Počkejte, než se diagnostika spustí a interpretuje výsledky.
Pokud byla údržba provedena v bráně virtuální sítě během období, kdy došlo ke ztrátě nebo latenci paketů. Je možné, že snížená kapacita brány přispěla k problémům s připojením, ke kterým dochází u cílové virtuální sítě. Postupujte podle doporučených kroků. Pokud chcete podporovat vyšší propustnost sítě a vyhnout se problémům s připojením během budoucích událostí údržby, zvažte upgrade skladové položky brány virtuální sítě.
Další kroky
Další informace nebo nápovědu najdete na následujících odkazech: