Az ExpressRoute-útválasztás optimalizálása
Ha több ExpressRoute-kapcsolatcsoporttal rendelkezik, több útvonalon csatlakozhat a Microsofthoz. Ennek eredményeképpen előfordulhat, hogy az útválasztás nem lesz optimális – azaz a forgalom hosszabb úton jut el a Microsofthoz, illetve a Microsofttól az Ön hálózatába. Minél hosszabb a hálózati útvonal, annál nagyobb a késés. A késés közvetlen hatással van az alkalmazás teljesítményére és a felhasználói élményre. Ez a cikk bemutatja ezt a problémát, és elmagyarázza, hogyan optimalizálhatja az útválasztást a szabványos útválasztási technológiákkal.
Elérési út kiválasztása a Microsoft és a nyilvános társviszony-létesítéshez
Fontos, hogy a Microsoft vagy a nyilvános társviszony-létesítés használatakor a forgalom a kívánt útvonalon haladjon át, ha egy vagy több ExpressRoute-kapcsolatcsoporttal rendelkezik. Gondoskodnia kell arról is, hogy az internet elérési útjai internetkapcsolatot (IX) vagy internetszolgáltatót (INTERNET-szolgáltatót) használjanak. A BGP a legjobb útvonalválasztási algoritmust használja számos tényező alapján, beleértve a leghosszabb előtag-egyezést (LPM). Annak biztosításához, hogy az Azure-ba a Microsofton vagy nyilvános társviszony-létesítésen keresztül irányuló forgalom áthaladjon az ExpressRoute útvonalán, implementálnia kell a Local Preference attribútumot. Ez a beállítás biztosítja, hogy az útvonal mindig az ExpressRoute-on legyen előnyben.
Megjegyzés
Az alapértelmezett helyi beállítás általában 100. A magasabb helyi beállításokat részesítik előnyben.
Tekintse meg a következő példaforgatókönyvet:
A fenti példában az ExpressRoute-útvonalak előnyben részesítéséhez konfigurálja a Helyi beállításokat az alábbiak szerint.
Cisco IOS-XE-konfiguráció R1 szempontból:
R1(config)#route-map prefer-ExR engedély 10
R1(config-route-map)#set local-preference 150
R1(config)#router BGP 345
R1(config-router)#neighbor 1.1.1.2 távoli, mint 12076
R1(config-router)#neighbor 1.1.1.2 aktiválása
R1(config-router)#neighbor 1.1.1.2 útvonaltérkép prefer-ExR a
Junos-konfiguráció az R1 szemszögéből:
- user@R1# set protocol bgp group ibgp type internal
- user@R1# set protocol bgp group ibgp local-preference 150
Optimálisnál rosszabb útválasztás az ügyféltől a Microsoft felé
Vizsgáljuk meg az útválasztási problémát egy példán keresztül. Tegyük fel, hogy van két irodája az Egyesült Államokban, egy Los Angelesben és egy New Yorkban. Az irodák egy nagykiterjedésű hálózaton (WAN) keresztül csatlakoznak, amely lehet a saját gerinchálózata vagy a szolgáltatója IP-alapú VPN hálózata. Két ExpressRoute-kapcsolatcsoporttal rendelkezik, az egyik az USA nyugati régiójában, a másik az USA keleti régiójában található. Mindkettő a WAN-on is csatlakoztatva van. Nyilvánvaló, hogy két útvonalon keresztül csatlakozhat a Microsoft hálózatához.
Most tegyük fel, hogy azure-beli üzemelő példánya van, például egy Azure App Service az USA nyugati régiójában és az USA keleti régiójában is. A szándéka az, hogy a Los Angeles-i felhasználókat az USA nyugati Azure-hoz, a New York-i felhasználókat pedig az USA keleti Azure-hoz kapcsolja. Ennek az az oka, hogy a szolgáltatásadminisztrátor azt hirdeti, hogy az egyes irodák felhasználói az optimális élmény érdekében hozzáférnek a közeli Azure-szolgáltatásokhoz. A terv jól működik a keleti part felhasználói számára, de a nyugati part felhasználói számára nem.
A probléma oka az egyes ExpressRoute-kapcsolatcsoportokon van, a helyszíni környezetben meghirdetjük mind az Usa keleti régiójában lévő Azure 23.100.0.0/16 előtagot, mind az Usa nyugati régiójában található előtagot 13.100.0.0/16. Ha nem tudja, hogy melyik előtag melyik régióból származik, nem tudja másképp kezelni. A WAN hálózat azt hiheti, hogy mindkét előtag közelebb van az USA keleti régiójához, mint az USA nyugati régiójához, és ezért mindkét iroda felhasználóit az USA keleti régiójában lévő ExpressRoute-kapcsolatcsoporthoz irányíthatja. Végül sok boldogtalan felhasználója van a Los Angeles-i irodában.
Megoldás: BGP-közösségek használata
Az útválasztás mindkét irodához való optimalizálásához ismernie kell, hogy melyik előtag származik az USA nyugati Azure-régiójából és melyik az USA keleti Azure-régiójából. Ezt az információt a BGP-közösség értékeivel kódoljuk. Egyedi BGP-közösségi értéket rendeltünk minden Azure-régióhoz, például 12076:51004 az USA keleti régiójához, 12076:51006 az USA nyugati régiójához. Most, hogy tudja, melyik előtag melyik Azure-régióból származik, konfigurálhatja, hogy melyik ExpressRoute-kapcsolatcsoportot részesíti előnyben. Mivel a BGP-t használjuk útválasztási adatok cseréjére, a BGP helyi beállításaival befolyásolhatja az útválasztást.
A példában magasabb helyi preferenciaértéket rendelhet hozzá a 13.100.0.0/16 előtaghoz az USA nyugati régiójában, mint az USA keleti régiójában, és hasonlóképpen magasabb helyi preferenciaértéket rendelhet hozzá a 23.100.0.0/16 előtaghoz az USA keleti régiójában, mint az USA nyugati régiójában. Ez a konfiguráció gondoskodik arról, hogy amikor a Microsoft mindkét elérési útja elérhető legyen, a Los Angeles-i felhasználók az USA nyugati régiójában található ExpressRoute-kapcsolatcsoportot választva csatlakozzanak az USA nyugati Azure-hoz, míg a New York-i felhasználók az USA keleti régiójában lévő ExpressRoute-ot az USA keleti Azure-jába. Az útválasztás minkét oldalon optimalizálva van.
Megjegyzés
Ugyanez a módszer alkalmazható a Helyi beállítás használatával az ügyfél és az Azure virtuális hálózat közötti útválasztásra privát társviszony-létesítés használatakor. A Microsoft nem címkéz BGP-közösségi értékeket az Azure-ból a hálózatra meghirdetett előtagokhoz. Mivel azonban tudja, hogy a virtuális hálózat melyik üzemelő példánya közel van az irodához, ennek megfelelően konfigurálhatja az útválasztókat úgy, hogy egy ExpressRoute-kapcsolatcsoportot részesítsen előnyben a másikhoz képest.
Optimálisnál rosszabb útválasztás a Microsofttól az ügyfél felé
Ebben a példában a Microsoft-kapcsolatok hosszabb utat vesznek igénybe a hálózat eléréséhez. Ebben az esetben helyszíni Exchange-kiszolgálókat és az Exchange Online-t használja egy hibrid környezetben. Az irodák egy WAN hálózathoz csatlakoznak. Mindkét irodában meghirdeti a helyszíni kiszolgálók előtagját a Microsoftnak két ExpressRoute-kapcsolatcsoporton keresztül.
Exchange Online kapcsolatokat kezdeményez a helyszíni kiszolgálókkal olyan esetekben, mint a postaláda áttelepítése. A Los Angeles-i irodával való kapcsolat az USA keleti régiójában található ExpressRoute-kapcsolatcsoporthoz lesz átirányítva, mielőtt visszajárja az egész kontinenst a nyugati partra. A probléma oka hasonló az első esetéhez. A Microsoft hálózata nem tudja megállapítani, hogy melyik helyszíni előtag közel van az USA keleti régiójához, és melyik közel van az USA nyugati régiójához. Emiatt a rossz útvonalat választja a Los Angeles-i irodához.
Megoldás: AS PATH előtag-beillesztés
A problémára két megoldás létezik. Az első az, hogy egyszerűen meghirdeti a helyszíni előtagját a Los Angeles-i office 177.2.0.0/31-hez az USA nyugati régiójában található ExpressRoute-kapcsolatcsoporton. Ezután meghirdeti a helyszíni előtagját a New York-i irodához, a 177.2.0.2/31-hez az USA keleti régiójában található ExpressRoute-kapcsolatcsoporton. Ennek eredményeképpen a Microsoft csak egy elérési utat biztosít az egyes irodákhoz való csatlakozáshoz. Nincs kétértelműség, és az útválasztás optimalizálva van. Ezzel a kialakítással kell kidolgoznia egy feladatátvételi stratégiát. Ha a Microsoft expressroute-on keresztüli elérési útja leáll, meg kell győződnie arról, hogy Exchange Online továbbra is tud csatlakozni a helyszíni kiszolgálókhoz.
A második megoldás az, hogy továbbra is meghirdeti mindkét előtagot mindkét ExpressRoute-kapcsolatcsoporton, és emellett egy tippet ad arról, hogy melyik előtag melyik irodához van közelebb. Mivel támogatjuk a BGP AS PATH előtag-beillesztést, konfigurálhatja az előtaghoz tartozó AS PATH előtag-beillesztést, és befolyásolhatja az útválasztást. Ebben a példában az USA keleti régiójában a 172.2.0.0/31 AS PATH értékét meghosszabbíthatja, hogy az USA nyugati régiójában lévő ExpressRoute-kapcsolatcsoportot részesítsük előnyben az ehhez az előtaghoz tartozó forgalom számára. Hasonlóképpen meghosszabbíthatja a 172.2.0.2/31 AS ELÉRÉSI ÚTJÁT az USA nyugati régiójában, hogy az USA keleti régiójában az ExpressRoute-kapcsolatcsoportot részesítsük előnyben. Az útválasztás mindkét iroda esetében optimalizálva van. Ezzel a kialakítással, ha az egyik ExpressRoute-kör megszakad, az Exchange Online továbbra is elérheti az Ön hálózatát a másik ExpressRoute-kapcsolatcsoporton és a WAN hálózaton keresztül.
Fontos
Eltávolítjuk a privát AS-számokat a Microsoft társviszony-létesítéskor kapott előtagok AS PATH-fájljában, amikor privát AS-számot használnak. Nyilvános AS-vel kell társviszonyt létesítenie, és hozzá kell fűznie a nyilvános AS-számokat az AS PATH-ban a Microsoft társviszony-létesítés útválasztásának befolyásolásához.
Megjegyzés
Bár az itt felsorolt példák a Microsoftra és a Nyilvános társviszony-létesítésre vonatkoznak, ugyanezek a funkciók a magánhálózati társviszony-létesítéshez is támogatottak. Emellett egyetlen ExpressRoute-kapcsolatcsoporton belül működik az AS Path előtag-beillesztés is, így befolyásolva az elsődleges és a másodlagos útvonalak kiválasztását.
Az optimálisnál rosszabb útválasztás a virtuális hálózatok között
Az ExpressRoute használatával engedélyezheti a virtuális hálózatról virtuális hálózatra (más néven „VNetre”) irányuló kommunikációt, ha egy ExpressRoute-kapcsolatcsoporthoz kapcsolja azokat. Amikor több ExpressRoute-kapcsolatcsoporthoz kapcsolja a hálózatokat, az optimálisnál rosszabb útválasztás történhet a VNetek között. Vegyünk egy példát. Két ExpressRoute-kapcsolatcsoporttal rendelkezik, az egyik az USA nyugati régiójában, a másik az USA keleti régiójában található. Mindkét régióban két VNet van. A webkiszolgálói az egyik VNeten vannak üzembe helyezve, az alkalmazáskiszolgálói pedig a másikon. A redundancia miatt a régiókban lévő két VNetet a helyi ExpressRoute-kapcsolatcsoporthoz és a távoli ExpressRoute-kapcsolatcsoporthoz is hozzákapcsolja. Ahogy az a következő ábrán is látható, mindegyik virtuális hálózatból két elérési út van a másik virtuális hálózathoz. A VNetek nem tudják, melyik ExpressRoute-kapcsolatcsoport helyi és melyik távoli. Mivel az egyenlő költségű többútvonalos (ECMP) útválasztás a virtuális hálózatok közötti forgalom terheléselosztására szolgál, egyes forgalomfolyamok hosszabb utat vesznek igénybe, és a távoli ExpressRoute-kapcsolatcsoporton lesznek irányítva.
Megoldás: nagyobb súly hozzárendelése a helyi kapcsolathoz
A megoldás egyszerű. Mivel tudja, hogy hol vannak a VNetek és a kapcsolatcsoportok, megmondhatja nekünk, hogy az egyes VNetek mely útvonalat részesítsék előnyben. Ebben a példában nagyobb súlyt rendel a helyi kapcsolathoz, mint a távoli kapcsolathoz (a példakonfigurációt itt találja). Ha egy virtuális hálózat több kapcsolaton kapja meg a másik virtuális hálózat előtagját, a legnagyobb súlyú kapcsolatot részesíti előnyben az adott előtag felé irányuló forgalom elküldéséhez.
Megjegyzés
A virtuális hálózatról a helyszíni hálózatra történő útválasztást is befolyásolhatja, ha több ExpressRoute-kapcsolatcsoporttal rendelkezik, a kapcsolat súlyának konfigurálásával ahelyett, hogy AS PATH előtagolást alkalmaz, ez a második forgatókönyvben ismertetett technika. Mindegyik előtag esetében először mindig a kapcsolat súlyát vesszük figyelembe az AS PATH hossza előtt a forgalom elküldési módjának meghatározásához.