Az Azure Route Server hibáinak elhárítása

Megtudhatja, hogyan háríthatja el az Azure Route Server néhány gyakori problémáját.

Csatlakozási problémák

Miért veszíti el a hálózati virtuális berendezés (NVA) az internetkapcsolatot, miután meghirdeti az alapértelmezett útvonalat (0.0.0.0.0/0) az útvonalkiszolgálóra?

Amikor az NVA meghirdeti az alapértelmezett útvonalat, az útválasztási kiszolgáló a virtuális hálózat összes virtuális gépére (virtuális gépére) leprogramozza, beleértve magát az NVA-t is. Ez az alapértelmezett útvonal az NVA-t állítja be az összes internethez kötött forgalom következő ugrásaként. Ha az NVA-nak internetkapcsolatra van szüksége, konfigurálnia kell egy felhasználó által megadott útvonalat (UDR), hogy felülbírálja ezt az alapértelmezett útvonalat az NVA-ból, és csatolja az UDR-t ahhoz az alhálózathoz, ahol az NVA üzemel. Ellenkező esetben az NVA-gazdagép folyamatosan küldi az internethez kötött forgalmat, beleértve azt is, amelyet az NVA küldött vissza magának az NVA-nak. További információ: felhasználó által megadott útvonalak.

Miért veszíti el az NVA a kapcsolatát az útvonalkiszolgálóval, miután a GatewaySubnet felhasználó által definiált útvonalával (UDR) kényszeríti a tűzfal felé irányuló összes forgalmat?

Ha tűzfallal szeretné megvizsgálni a helyszíni forgalmat, a GatewaySubneten (az UDR-t tartalmazó GatewaySubnethez társított útvonaltáblával) kényszerítheti a tűzfalra irányuló összes helyszíni forgalmat egy felhasználó által megadott útvonal (UDR) használatával. Ez az UDR azonban megszakíthatja az útválasztási kiszolgáló és az átjáró közötti kommunikációt azáltal, hogy a vezérlősík forgalmát (BGP) a tűzfalra kényszeríti (ez a probléma akkor fordul elő, ha az útvonalkiszolgálót tartalmazó virtuális hálózat felé irányuló forgalmat vizsgálja). A probléma elkerülése érdekében egy másik UDR-t kell hozzáadnia a GatewaySubnet útvonaltáblához, hogy a vezérlősík forgalmát ne kényszerítse a tűzfalra (ha nem kíván/lehetséges BGP-szabályt hozzáadni a tűzfalhoz):

A 10.0.0.0/16 a virtuális hálózat címtere, a 10.0.1.0/27 pedig a RouteServerSubnet címtere. A 10.0.2.1 a tűzfal IP-címe.

Hozzáadtam egy felhasználó által definiált útvonalat (UDR) a következő ugrási típussal virtuális hálózati átjáróként, de ez az UDR nem lép érvénybe. Ez várható?

Igen, ez a várt viselkedés. A következő ugrás típusú virtuális hálózati átjáróval rendelkező, felhasználó által definiált útvonalak nem támogatottak az útválasztási kiszolgáló virtuális hálózatán és társhálózatán belüli alhálózatok esetében. Ha azonban hálózati virtuális berendezésnek (NVA) vagy internetnek szeretné konfigurálni a következő ugrást, akkor támogatott egy felhasználó által megadott útvonal hozzáadása a következő ugrástípussal , a VirtualAppliance vagy az Internet használatával.

A virtuális gép hálózati adapterének érvényes útvonalai között miért van egy felhasználó által definiált útvonal (UDR), amelynek következő ugrástípusa Nincs?

Ha egy olyan útvonalat hirdet meg az NVA-ból az Útvonalkiszolgálóra, amely pontosan egyezik egy másik felhasználó által megadott útvonaléval, akkor a meghirdetett útvonal következő ugrásának érvényesnek kell lennie. Ha a meghirdetett következő ugrás egy terheléselosztó konfigurált háttérkészlet nélkül, akkor ez az érvénytelen útvonal elsőbbséget élvez a felhasználó által megadott útvonalsal szemben. A hálózati adapter érvényes útvonalaiban az érvénytelen meghirdetett útvonal felhasználó által megadott útvonalként jelenik meg, a következő ugrástípus pedig Nincs.

Miért veszítem el a kapcsolatot, miután egy szolgáltatásvégpont-szabályzatot társítottam a RouteServerSubnethez vagy a GatewaySubnethez?

Ha szolgáltatásvégpont-szabályzatot társít a RouteServerSubnethez vagy a GatewaySubnethez, akkor megszakadhat a kommunikáció az Azure mögöttes felügyeleti platformja és a megfelelő Azure-szolgáltatások (Route Server és VPN/ExpressRoute-átjáró) között. Ez azt eredményezheti, hogy ezek az Azure-erőforrások nem megfelelő állapotba kerülnek, ami a helyszíni és az Azure-számítási feladatok közötti kapcsolatvesztést okozhatja.

Miért veszítem el a kapcsolatot az egyéni DNS használata után a Route Server virtuális hálózatának alapértelmezett (Azure által biztosított DNS) helyett?

Ha nem az alapértelmezett (Azure által biztosított) DNS-t használja, a Route Server által üzembe helyezett virtuális hálózat esetében győződjön meg arról, hogy az egyéni DNS-konfiguráció képes feloldani a nyilvános tartományneveket. Ez biztosítja, hogy az Azure-szolgáltatások (Route Server és VPN/ExpressRoute-átjáró) képesek legyenek kommunikálni az Azure mögöttes felügyeleti síkjával. További információkért tekintse meg a helyettesítő karakterekre vonatkozó szabályokat az Azure DNS Private Resolver dokumentációjában.

Miért nem tudok TCP-pingelni az NVA-ról az útválasztási kiszolgáló BGP-társ IP-címére, miután beállítottam közöttük a BGP-társviszonyt?

Egyes NVA-kban statikus útvonalat kell hozzáadnia az Útválasztási kiszolgáló alhálózatához, hogy tcp-pingelhesse az útválasztási kiszolgálót az NVA-ból, és elkerülje a BGP-társviszony-létesítést. Ha például az útválasztási kiszolgáló a 10.0.255.0/27-es verzióban van, és az NVA a 10.0.1.0/24-es verzióban van, az alábbi útvonalat kell hozzáadnia az útválasztási táblához az NVA-ban:

A 10.0.1.1 az alapértelmezett átjáró IP-címe abban az alhálózatban, ahol az NVA (pontosabban az egyik hálózati adapter) üzemel.

Miért veszítem el a kapcsolatot a helyszíni hálózatommal az ExpressRoute-on és/vagy az Azure VPN-en keresztül, amikor egy útvonalkiszolgálót helyezek üzembe egy olyan virtuális hálózaton, amely már rendelkezik ExpressRoute-átjáróval és/vagy Azure VPN-átjáróval?

Amikor útválasztási kiszolgálót helyez üzembe egy virtuális hálózaton, frissíteni kell a vezérlősíkot az átjárók és a virtuális hálózat között. A frissítés során előfordulhat, hogy a virtuális hálózat virtuális gépei megszakadnak a helyszíni hálózathoz való kapcsolódás során. Határozottan javasoljuk, hogy ütemezze a karbantartást, hogy üzembe helyezzen egy útvonalkiszolgálót az éles környezetben.

Vezérlősíkokkal kapcsolatos problémák

Miért nem kapja meg az Azure VPN Gatewayhez csatlakoztatott helyszíni hálózatom az útvonalkiszolgáló által meghirdetett alapértelmezett útvonalat?

Bár az Azure VPN Gateway képes fogadni az alapértelmezett útvonalat a BGP-társától, beleértve az útválasztási kiszolgálót is, nem hirdeti meg az alapértelmezett útvonalat más társokkal.

Miért nem kap útvonalakat az NVA az útvonalkiszolgálótól annak ellenére, hogy a BGP-társviszony működik?

Az útvonalkiszolgáló által használt ASN a 65515. Győződjön meg arról, hogy egy másik ASN-t konfigurál az NVA-hoz, hogy létre lehessen hozni egy eBGP-munkamenetet az NVA és az útvonalkiszolgáló között, hogy az útvonalak propagálása automatikusan megtörténjen. Győződjön meg arról, hogy engedélyezi a "multi-hop" beállítást a BGP-konfigurációban, mert az NVA és az útvonalkiszolgáló a virtuális hálózat különböző alhálózataiban található.

Miért nem működik a kapcsolat, ha 0 ASN-vel hirdetek útvonalakat az AS-Pathban?

Az Azure Route Server a 0 ASN-et tartalmazó útvonalakat elveti az AS-pathban. Annak érdekében, hogy ezek az útvonalak sikeresen meghirdethetők legyenek az Azure-ban, az AS-path nem tartalmazhat 0-t.

Az NVA és az útvonalkiszolgáló közötti BGP-társviszony működik. Látom, hogy az útvonalak megfelelően cserélődnek közöttük. Miért nem szerepelnek az NVA-útvonalak a virtuális gépem érvényes útválasztási táblájában?

• Ha a virtuális gép ugyanabban a virtuális hálózatban van, mint az NVA és az útvonalkiszolgáló:

  Az útválasztási kiszolgáló két BGP-társ IP-címet tesz elérhetővé, amelyek az útvonalaknak a virtuális hálózaton futó összes többi virtuális gépre való küldésével kapcsolatosak. Minden NVA-nak két azonos BGP-munkamenetet kell beállítania (például ugyanazt az AS-számot, ugyanazt az AS-útvonalat kell használnia, és ugyanazt az útvonalkészletet kell meghirdetnie) a két BGP-társ IP-címhez, hogy a virtuális hálózat virtuális gépei konzisztens útválasztási adatokat kapjanak az Azure Route Serverről.

  

  Ha az NVA két vagy több példányával rendelkezik, különböző AS-útvonalakat hirdethet ugyanahhoz az útvonalhoz különböző NVA-példányoktól, ha egy NVA-példányt aktívként, a másik passzívat szeretne kijelölni.

• Ha a virtuális gép más virtuális hálózatban van, mint az NVA-t és az útvonalkiszolgálót üzemeltető. Ellenőrizze, hogy engedélyezve van-e a virtuális hálózatok közötti társviszony-létesítés a két virtuális hálózat között, és hogy engedélyezve van-e a távoli útvonalkiszolgáló használata a virtuális gép virtuális hálózatán.

Miért van kikapcsolva az ExpressRoute egyenlő költségű többútvonalos (ECMP) funkciója, miután üzembe helyeztem az Útválasztási kiszolgálót a virtuális hálózaton?

Ha ugyanazokat az útvonalakat hirdeti meg a helyszíni hálózatról az Azure-ba több ExpressRoute-kapcsolaton keresztül, az ECMP alapértelmezés szerint engedélyezve van az azure-ból a helyszíni hálózatba irányuló ezen útvonalakra irányuló forgalom esetében. Az Útvonalkiszolgáló telepítésekor jelenleg több útvonal adatai elvesznek az ExpressRoute és az útvonalkiszolgáló közötti BGP-cserében, ezért az Azure-ból érkező forgalom csak az egyik ExpressRoute-kapcsolaton halad át.

Működési problémák

Miért jelenik meg hiba a Route Server-műveletek végrehajtásához szükséges érvénytelen hatókörrel és engedélyezéssel kapcsolatban?

Ha az alábbi formátumban hibaüzenet jelenik meg, győződjön meg arról, hogy a következő engedélyek vannak konfigurálva: Útvonalkiszolgálói szerepkörök és engedélyek

Hibaüzenet formátuma: "Az objektumazonosítóval {} rendelkező ügyfél nem rendelkezik engedéllyel a művelet {}{} hatókörön keresztüli végrehajtására, vagy a hatókör érvénytelen. Ha a hozzáférés nemrég lett engedélyezve, frissítse a hitelesítő adatait.”

Következő lépés

Az Azure Route Server létrehozásához és konfigurálásához lásd: