Verify ExpressRoute connectivity
Ez a cikk segít az Azure ExpressRoute-kapcsolat ellenőrzésében és hibaelhárításában. Az ExpressRoute egy helyszíni hálózatot terjeszt ki a Microsoft Cloudba egy olyan privát kapcsolaton keresztül, amelyet általában egy kapcsolatszolgáltató tesz lehetővé. Az ExpressRoute-kapcsolat hagyományosan három különböző hálózati zónát foglal magában:
- Ügyfélhálózat
- Szolgáltatói hálózat
- Microsoft-adatközpont
Megjegyzés:
Az ExpressRoute Direct kapcsolati modellben közvetlenül csatlakozhat a Microsoft Enterprise Edge (M Standard kiadás E) útválasztók portjához. A közvetlen kapcsolati modell csak az Ön és a Microsoft hálózati zónáit tartalmazza.
Ez a cikk segít azonosítani, hogy létezik-e kapcsolati probléma, és hol. Ezután a megfelelő csapattól kérhet támogatást a probléma megoldásához.
Fontos
Ez a cikk az egyszerű problémák diagnosztizálásában és megoldásában nyújt segítséget. Ez nem a Microsoft támogatásának helyettesítésére szolgál. Ha nem tudja megoldani a problémát a jelen cikkben található útmutatással, nyisson meg egy támogatási jegyet Microsoft ügyfélszolgálata.
Áttekintés
Az alábbi ábra egy ügyfélhálózat logikai kapcsolatát mutatja be a Microsoft-hálózattal az ExpressRoute-on keresztül.
Az előző ábrán a számok a főbb hálózati pontokat jelölik:
- Ügyfél számítási eszköze (például kiszolgáló vagy számítógép).
- Ügyféloldali útválasztók (CEs).
- Szolgáltatói peremhálózati útválasztók/kapcsolók (PC-k), amelyek az ügyfél peremhálózati útválasztóival néznek szembe.
- Microsoft Enterprise Edge ExpressRoute-útválasztókkal (M Standard kiadás Es) szembesülő számítógépek. Ez a cikk PE-M Standard kiadás E-nek hívja őket.
- M Standard kiadás es.
- Virtuális hálózati átjáró.
- Számítási eszköz az Azure-beli virtuális hálózaton.
Ez a cikk időnként a hozzájuk tartozó szám alapján hivatkozik ezekre a hálózati pontokra.
Az ExpressRoute csatlakozási modelljétől függően a 3. és 4. hálózati pontok lehetnek kapcsolók (2. rétegű eszközök) vagy útválasztók (3. rétegű eszközök). Az ExpressRoute csatlakozási modelljei a felhőcsere-kolokáció, a pont-pont Ethernet-kapcsolat vagy a tetszőleges (IPVPN).
A közvetlen kapcsolódási modellben nincsenek 3. és 4. hálózati pontok. Ehelyett a CE-k (2) közvetlenül az MSEE-khez kapcsolódnak sötét szálon keresztül.
Ha a felhőközpont kolokációs, pont-pont Ethernet vagy közvetlen csatlakozási modellt használnak, a CE-k (2) BGP (Border Gateway Protocol) peeringet hoznak létre az MSEE-kkel (5).
Ha az "any-to-any" (IPVPN) kapcsolati modellt használják, a PE-MSEE-k (4) BGP peeringet hoznak létre az MSEE-kkel (5). A PE-MSEE-k a Microsofttól kapott útvonalakat az IPVPN-szolgáltató hálózatán keresztül továbbítják vissza az ügyfélhálózatba.
Megjegyzés:
A magas rendelkezésre állás érdekében a Microsoft teljesen redundáns párhuzamos kapcsolatot hoz létre az M Standard kiadás E és a PE-M Standard kiadás E párok között. A teljes mértékben redundáns párhuzamos hálózati útvonalat is javasoljuk az ügyfélhálózat és a PE/CE párok között. A magas rendelkezésre állásról további információt az ExpressRoute-tal való magas rendelkezésre állás tervezése című cikkben talál.
Az alábbi szakaszok az ExpressRoute-kapcsolatcsoportok hibaelhárításának logikai lépéseit ismertetik.
A kapcsolatcsoport kiépítésének és állapotának ellenőrzése
Az ExpressRoute-kapcsolatcsoport kiépítése redundáns 2. rétegbeli kapcsolatot hoz létre a CEs/PE-M Standard kiadás Es (2/4) és az M Standard kiadás Es (5) között. Az ExpressRoute-kapcsolatcsoportok létrehozásáról, módosításáról, kiépítéséről és ellenőrzéséről további információt az ExpressRoute-kapcsolatcsoportok létrehozása és módosítása című cikkben talál.
Tipp.
A szolgáltatáskulcsok egyedileg azonosítják az ExpressRoute-kapcsolatcsoportokat. Ha segítségre van szüksége a Microsofttól vagy egy ExpressRoute-partnertől egy ExpressRoute-probléma elhárításához, adja meg a szolgáltatáskulcsot a kapcsolatcsoport egyszerű azonosításához.
Ellenőrzés az Azure Portalon
Az Azure Portalon nyissa meg az ExpressRoute-kapcsolatcsoport lapját. A 
lap szakasza felsorolja az ExpressRoute alapvető részeit, ahogyan az alábbi képernyőképen látható:
Az ExpressRoute alapjaiban a kapcsolatcsoport állapota a Kapcsolatcsoport állapotát jelzi a Microsoft oldalán. A szolgáltató állapota azt jelzi, hogy a kapcsolatcsoport ki van-e építve vagy nincs kiépítve a szolgáltató oldalán.
Ahhoz, hogy egy ExpressRoute-kapcsolatcsoport működőképes legyen, a kapcsolatcsoport állapotát engedélyezni kell, a szolgáltató állapotát pedig ki kell építeni.
Megjegyzés:
Miután konfigurált egy ExpressRoute-kapcsolatcsoportot, ha a kapcsolatcsoport állapota nem engedélyezett állapotban van, lépjen kapcsolatba Microsoft ügyfélszolgálata. Ha a szolgáltató állapota nem kiépített állapotban van, forduljon a szolgáltatóhoz.
Ellenőrzés a PowerShell-lel
Egy erőforráscsoport összes ExpressRoute-kapcsolatcsoportjának listázásához használja a következő parancsot:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
Tipp.
Ha egy erőforráscsoport nevét keresi, a parancs használatával megjelenítheti az Get-AzResourceGroup előfizetés összes erőforráscsoportját.
Ha egy adott ExpressRoute-kapcsolatcsoportot szeretne kijelölni egy erőforráscsoportban, használja a következő parancsot:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Íme egy példa egy válaszra:
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 : []
Annak ellenőrzéséhez, hogy az ExpressRoute-kapcsolatcsoport működik-e, különös figyelmet kell fordítani a következő mezőkre:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Megjegyzés:
Az ExpressRoute-kapcsolatcsoport konfigurálása után, ha a kapcsolatcsoport állapota nem engedélyezett állapotban van, lépjen kapcsolatba Microsoft ügyfélszolgálata. Ha a szolgáltató állapota nem kiépített állapotban van, forduljon a szolgáltatóhoz.
Társviszony-létesítési konfiguráció ellenőrzése
Miután a szolgáltató befejezte az ExpressRoute-kapcsolatcsoport kiépítését, több, külső BGP-n (eBGP) alapuló útválasztási konfiguráció hozható létre az ExpressRoute-kapcsolatcsoporton keresztül a CEs/M Standard kiadás E-PEs (2/4) és az M Standard kiadás Es (5) között. Minden ExpressRoute-kapcsolatcsoporthoz tartozhat az alábbi társviszony-létesítési konfigurációk egyike vagy mindkettő:
- Azure-beli privát társviszony-létesítés: privát virtuális hálózatok felé történő forgalom az Azure-ban
- Microsoft-társviszony: a szolgáltatásként nyújtott platform (PaaS) és a szolgáltatásként nyújtott szoftver (SaaS) nyilvános végpontjai felé történő forgalom
Az útválasztási konfiguráció létrehozásáról és módosításáról az ExpressRoute-kapcsolatcsoport útválasztásának létrehozása és módosítása című cikkben talál további információt.
Ellenőrzés az Azure Portalon
Megjegyzés:
Egy IPVPN-kapcsolati modellben a szolgáltatók kezelik a társviszonyok (3. rétegbeli szolgáltatások) konfigurálásának felelősségét. Ilyen modellben, miután a szolgáltató konfigurálta a társviszonyt, és ha a társviszony-létesítés üres a portálon, próbálja meg frissíteni a kapcsolatcsoport konfigurációját a portál frissítési gombjának használatával. Ez a művelet lekéri az aktuális útválasztási konfigurációt a kapcsolatcsoportból.
Az Azure Portalon ellenőrizheti egy ExpressRoute-kapcsolatcsoport állapotát az adott kapcsolatcsoport oldalán. A lap szakasza felsorolja az ExpressRoute-társviszonyokat az alábbi képernyőképen látható módon:
Az előző példában az Azure-beli privát társviszony-létesítés ki van építve, de az Azure nyilvános és a Microsoft-társviszonyok nem lesznek kiépítve. A sikeresen kiépített társviszony-létesítési környezetekben az elsődleges és a másodlagos pont–pont alhálózat is szerepel. A /30 alhálózatok az M Standard kiadás Es és a CEs/PE-M Standard kiadás E interfész IP-címéhez használatosak. A kiépített társviszonyok esetében a lista azt is jelzi, hogy ki módosította utoljára a konfigurációt.
Megjegyzés:
Ha a társviszony-létesítés engedélyezése sikertelen, ellenőrizze, hogy a hozzárendelt elsődleges és másodlagos alhálózatok megfelelnek-e a csatolt CE/PE-M Standard kiadás E konfigurációjának. Azt is ellenőrizze, hogy a helyes VlanId, AzureASNés PeerASN az értékek vannak-e használva az M Standard kiadás Esen, és hogy ezek az értékek megfeleltethetők-e a csatolt CE/PE-M Standard kiadás E-n használt értékeknek.
Ha az MD5 kivonatolást választja, a megosztott kulcsnak azonosnak kell lennie az M Standard kiadás E és a CE/PE-M Standard kiadás E párokon. A korábban konfigurált megosztott kulcsok biztonsági okokból nem jelennek meg.
Ha egy M Standard kiadás E útválasztón módosítania kell bármelyik konfigurációt, tekintse meg az ExpressRoute-kapcsolatcsoport útválasztásának létrehozását és módosítását.
Megjegyzés:
Az interfészhez hozzárendelt /30 alhálózaton a Microsoft az M Standard kiadás E felület alhálózatának második használható IP-címét választja ki. Ezért győződjön meg arról, hogy az alhálózat első használható IP-címe a társviszonyban lévő CE/PE-M Standard kiadás E-n lett hozzárendelve.
Ellenőrzés a PowerShell-lel
Az Azure privát társviszony-létesítés konfigurációs adatainak lekéréséhez használja az alábbi parancsokat:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
Íme egy példa válasz egy sikeresen konfigurált privát társviszony-létesítéshez:
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
A sikeresen engedélyezett társviszony-létesítési környezetekben szerepelnének az elsődleges és másodlagos címelőtagok. A /30 alhálózatok az M Standard kiadás Es és a CEs/PE-M Standard kiadás E interfész IP-címéhez használatosak.
Az Azure nyilvános társviszony-létesítés konfigurációs adatainak lekéréséhez használja az alábbi parancsokat:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePublicPeering" -ExpressRouteCircuit $ckt
A Microsoft társviszony-létesítés konfigurációs adatainak lekéréséhez használja az alábbi parancsokat:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt
Ha nincs konfigurálva társviszony-létesítés, hibaüzenet jelenik meg. Íme egy példa válasz arra az esetre, ha a megadott társviszony-létesítés (ebben az esetben az Azure nyilvános társviszony-létesítés) nincs konfigurálva a kapcsolatcsoporton belül:
Get-AzExpressRouteCircuitPeeringConfig : Sequence contains no matching element
At line:1 char:1
+ Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePublicPeering ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzExpr...itPeeringConfig], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Network.GetAzureExpressRouteCircuitPeeringConfigCommand
Megjegyzés:
Ha a társviszony-létesítés engedélyezése sikertelen, ellenőrizze, hogy a hozzárendelt elsődleges és másodlagos alhálózatok megfelelnek-e a csatolt CE/PE-M Standard kiadás E konfigurációjának. Azt is ellenőrizze, hogy a helyes VlanId, AzureASNés PeerASN az értékek vannak-e használva az M Standard kiadás Esen, és hogy ezek az értékek megfeleltethetők-e a csatolt CE/PE-M Standard kiadás E-n használt értékeknek.
Ha az MD5 kivonatolást választja, a megosztott kulcsnak azonosnak kell lennie az M Standard kiadás E és a CE/PE-M Standard kiadás E párokon. A korábban konfigurált megosztott kulcsok biztonsági okokból nem jelennek meg.
Ha egy M Standard kiadás E útválasztón módosítania kell bármelyik konfigurációt, tekintse meg az ExpressRoute-kapcsolatcsoport útválasztásának létrehozását és módosítását.
Megjegyzés:
Az interfészhez hozzárendelt /30 alhálózaton a Microsoft az M Standard kiadás E felület alhálózatának második használható IP-címét választja ki. Ezért győződjön meg arról, hogy az alhálózat első használható IP-címe a társviszonyban lévő CE/PE-M Standard kiadás E-n lett hozzárendelve.
ARP ellenőrzése
The Address Resolution Protocol (ARP) table provides a mapping of the IP address and MAC address for a particular peering. The ARP table for an ExpressRoute circuit peering provides the following information for each interface (primary and secondary):
- Mapping of the IP address for the on-premises router interface to the MAC address
- Mapping of the IP address for the ExpressRoute router interface to the MAC address (optional)
- Age of the mapping
ARP tables can help validate layer 2 configuration and troubleshoot basic layer 2 connectivity issues.
Megjegyzés:
A hardverplatformtól függően az ARP-eredmények eltérőek lehetnek, és csak a helyszíni felületet jelenítik meg.
Ha szeretné megtudni, hogyan tekintheti meg az ExpressRoute-társviszony ARP-tábláját, és hogyan használhatja fel az információkat a 2. réteg csatlakozási problémáinak elhárítására, olvassa el az ARP-táblák lekérése a Resource Manager-alapú üzemi modellben című témakört.
BGP és útvonalak ellenőrzése az M Standard kiadás E-n
Ha le szeretné szerezni az útválasztási táblát az M Standard kiadás E-ből a privát útválasztási környezet elsődleges útvonalán, használja a következő parancsot:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****
Íme egy példa egy válaszra:
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##
Megjegyzés:
Ha egy M Standard kiadás E és egy CE/PE-M közötti eBGP-társviszony állapota aktív vagy tétlen Standard kiadás ellenőrizze, hogy a hozzárendelt elsődleges és másodlagos társalhálózatok megfelelnek-e a csatolt CE/PE-M Standard kiadás E konfigurációjának. Azt is ellenőrizze, hogy a helyes VlanId, AzureASNés PeerASN az értékek vannak-e használva az M Standard kiadás Esen, és hogy ezek az értékek megfeleltethetők-e a csatolt CE/PE-M Standard kiadás E-n használt értékeknek. Ha az MD5 kivonatolást választja, a megosztott kulcsnak azonosnak kell lennie az M Standard kiadás E és a CE/PE-M Standard kiadás E párokon. Ha egy M Standard kiadás E útválasztón módosítania kell bármelyik konfigurációt, tekintse meg az ExpressRoute-kapcsolatcsoport útválasztásának létrehozását és módosítását.
Megjegyzés:
Ha bizonyos célhelyek nem érhetők el társviszony-létesítésen keresztül, ellenőrizze az M Standard kiadás Es útvonaltábláját a megfelelő társviszony-létesítési környezetben. Ha az útválasztási táblában található egy egyező előtag (lehet naTed IP), ellenőrizze, hogy az útvonalon található tűzfalak, hálózati biztonsági csoportok vagy hozzáférés-vezérlési listák (ACL-ek) blokkolják-e a forgalmat.
Az alábbi példa a nem létező társviszony-létesítés parancsának válaszát mutatja be:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
A forgalom megerősítése
A társviszony-létesítési környezet összesített elsődleges és másodlagos elérésiút-forgalmi statisztikáinak (bájtok be- és kimenő) lekéréséhez használja a következő parancsot:
Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'
Íme egy példa a parancs kimenetére:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Íme egy példa a nem létező társviszony-létesítés parancsának kimenetére:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
A privát társhálózat kapcsolati tesztelése
A privát társviszony-kapcsolat teszteléséhez számolja az ExpressRoute-kapcsolatcsoport Microsoft-peremhálózatát az M Standard kiadás E-eszközökön érkező és onnan kilépő csomagok számlálásával. Ez a diagnosztikai eszköz úgy működik, hogy ACL-t alkalmaz az MSEE-ra, hogy megszámolja az adott ACL-szabályokat elérő csomagok számát. Ezzel az eszközzel megerősítheti a kapcsolatot az olyan kérdések megválaszolásával, mint például:
- A csomagjaim eljutnak az Azure-ba?
- Visszatérnek a helyszínre?
Teszt futtatása
A diagnosztikai eszköz eléréséhez válassza az ExpressRoute-kapcsolatcsoport problémáinak diagnosztizálása és megoldása lehetőséget az Azure Portalon.
Válassza Csatlakozás ivity > Performance Issues (Teljesítményproblémák) lehetőséget.
A
Görgessen le a Privát társviszony-létesítés tesztelése szakaszhoz, és bontsa ki.
Futtassa a PsPing-tesztet a helyszíni IP-címről az Azure IP-címére, és futtassa a kapcsolati teszt során.
Töltse ki az űrlap mezőit. Mindenképpen adja meg ugyanazokat a helyszíni és Azure IP-címeket, amelyeket az 5. lépésben használt. Ezután válassza a Küldés lehetőséget, és várja meg, amíg az eredmények betöltődnek.
Eredmények értelmezése
Ha az eredmények készen állnak, két készlettel rendelkezik az elsődleges és a másodlagos M Standard kiadás E-eszközökhöz. Tekintse át a be- és kimenő egyezések számát, és használja az alábbi forgatókönyveket az eredmények értelmezéséhez:
Mindkét MSEE-n küldött és fogadott csomagegyezések láthatók: Ez az eredmény azt jelzi, hogy a kapcsolatcsoport MSEE-jeibe bejövő és kimenő forgalom kifogástalan. Ha a veszteség a helyszínen vagy az Azure-ban jelentkezik, az az MSEE-ktől lefelé történik.
Ha helyszíniről az Azure-ba teszteli a PsPing-et, a kapott eredmények egyezéseket mutatnak, de az elküldött eredmények nem egyeznek: Ez az eredmény azt jelzi, hogy a forgalom az Azure-ba érkezik, de nem tér vissza a helyszínire. Ellenőrizze a visszatérési útvonal útválasztási problémáit. Például a megfelelő előtagokat hirdeti meg az Azure-ban? A felhasználó által definiált útvonal (UDR) felülírja az előtagokat?
Ha Azure-ból a helyszínibe teszteli a PsPing-et, a küldött eredmények egyezéseket mutatnak, de a kapott eredmények nem egyeznek: Ez az eredmény azt jelzi, hogy a forgalom a helyszínibe érkezik, de nem tér vissza az Azure-ba. A szolgáltatóval együttműködve megtudhatja, miért nem irányítja a forgalmat az Azure-ba az ExpressRoute-kapcsolatcsoporton keresztül.
Az egyik MSEE nem jelenít meg egyezést, a másik viszont jó egyezéseket mutat: Ez az eredmény azt jelzi, hogy egy MSEE nem fogad vagy nem ad át semmilyen forgalmat. Lehet, hogy offline állapotban van (például a BGP/ARP leállt).
- A nem kifogástalan elérési út megerősítéséhez további teszteket is futtathat, ha egy egyedi /32-es helyszíni útvonalat hirdet meg a BGP-munkameneten ezen az útvonalon.
- Futtassa a „Privát társhálózat-létesítési kapcsolat tesztelése” parancsot a helyszíni célcímként meghirdetett egyedi /32 használatával, és tekintse át az eredményeket az elérési út állapotának megerősítéséhez.
Az egyes MSEE-eszközökre vonatkozó teszteredmények a következő példához hasonlóan néznek ki:
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
A teszt eredménye a következő tulajdonságokkal rendelkezik:
- IP-port: 3389
- Helyszíni IP-cím CIDR: 10.0.0.0
- Azure IP-cím CIDR: 20.0.0.0
A virtuális hálózati átjáró rendelkezésre állásának ellenőrzése
Az ExpressRoute virtuális hálózati átjáró megkönnyíti az Azure-beli virtuális hálózaton üzembe helyezett privát kapcsolati szolgáltatásokhoz és privát IP-címekhez való felügyeleti és vezérlési síkkapcsolatot. A Microsoft felügyeli a virtuális hálózati átjáró infrastruktúrát, és időnként karbantartáson megy keresztül.
A karbantartási időszak alatt a virtuális hálózati átjáró teljesítménye csökkenhet. A virtuális hálózat csatlakozási problémáinak elhárításához és annak megtekintéséhez, hogy a legutóbbi karbantartási esemény csökkentett kapacitást okozott-e, kövesse az alábbi lépéseket:
Válassza az ExpressRoute-kapcsolatcsoport problémáinak diagnosztizálása és megoldása lehetőséget az Azure Portalon.
Válassza a Teljesítményproblémák lehetőséget.
Várja meg, amíg a diagnosztika fut, és értelmezi az eredményeket.
Ha a karbantartás a virtuális hálózati átjárón történt egy olyan időszakban, amikor csomagvesztést vagy késést tapasztalt. Lehetséges, hogy az átjáró csökkentett kapacitása hozzájárult a célzott virtuális hálózat csatlakozási problémáihoz. Follow the recommended steps. A nagyobb hálózati átviteli sebesség támogatásához és a jövőbeli karbantartási események során felmerülő csatlakozási problémák elkerüléséhez fontolja meg a virtuális hálózati átjáró termékváltozatának frissítését.
További lépések
További információért vagy segítségért tekintse meg az alábbi hivatkozásokat: