Optimalizace směrování ExpressRoute
Pokud máte víc okruhů ExpressRoute, máte více než jednu cestu, jak se připojit k Microsoftu. V důsledku toho může dojít k neoptimálnímu směrování, to znamená, že přenosy dat mezi vaší sítí a Microsoftem mohou použít delší cestu. Čím delší je síťová cesta, tím větší je latence. Latence má přímý vliv na výkon aplikace a uživatelské prostředí. Tento článek ukazuje tento problém a vysvětluje, jak optimalizovat směrování pomocí standardních technologií směrování.
Výběr cesty pro partnerský vztah Microsoftu
Pokud máte jeden nebo více okruhů ExpressRoute, je důležité zajistit, aby při využívání Microsoftu provoz přetékající přes požadovanou cestu. Potřebujete také zajistit, aby cesty k internetu používaly internet exchange (IX) nebo poskytovatele internetových služeb (ISP). Protokol BGP využívá algoritmus výběru nejlepší cesty na základě mnoha faktorů, včetně nejdelší shody předpon (LPM). Pokud chcete zajistit, aby provoz určený pro Azure prostřednictvím Microsoftu procházel cestou ExpressRoute, musíte implementovat atribut Místní předvolba. Toto nastavení zajistí, že cesta bude vždy upřednostňovaná pro ExpressRoute.
Poznámka:
Výchozí místní předvolba je obvykle 100. Preferují se vyšší místní předvolby.
Zvažte následující ukázkový scénář:
V předchozím příkladu chcete upřednostňovat cesty ExpressRoute, nakonfigurujte místní předvolbu následujícím způsobem.
Konfigurace Cisco IOS-XE z pohledu R1:
R1(config)#route-map prefer-ExR permit 10
R1(config-route-map)#set místní předvolba 150
R1(config)#router BGP 345
R1(config-router)#neighbor 1.1.1.2 remote-as 12076
R1(konfigurace-směrovač)#neighbor aktivace 1.1.1.2
R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in
Konfigurace Junos z pohledu R1:
- user@R1# set protocols bgp group ibgp type internal
- user@R1# set protocols bgp group ibgp local-preference 150
Neoptimální směrování od zákazníka do Microsoftu
Podívejme se zblízka na problém směrování na příkladu. Představte si, že máte dvě pobočky v USA, jednu v Los Angeles a jednu v New Yorku. Vaše pobočky jsou připojené k síti WAN, což může být buď vaše páteřní síti, nebo virtuální privátní síť IP poskytovatele služeb. Máte dva okruhy ExpressRoute, jeden v oblasti USA – západ a druhý v oblasti USA – východ. Obě jsou také připojené k síti WAN. Zjevně máte dvě cesty, jak se připojit k síti Microsoftu.
Teď si představte, že máte nasazení Azure, například službu Aplikace Azure v oblasti USA – západ i USA – východ. Vaším záměrem je propojit uživatele v Los Angeles s Azure USA – západ a vašimi uživateli v New Yorku s Azure USA – východ. Důvodem tohoto nastavení je to, že správce služeb inzeruje, že uživatelé v každé kanceláři přistupují k blízkým službám Azure pro optimální prostředí. Plán funguje dobře pro uživatele východního pobřeží, ale ne pro uživatele západního pobřeží.
Příčinou problému je každý okruh ExpressRoute, inzerujeme místní předponu v Azure USA – východ 23.100.0.0/16 a předponu v Azure USA – západ 13.100.0.0/16. Pokud nevíte, která předpona je z jaké oblasti, nemůžete ji považovat za odlišnou. Vaše síť WAN si může myslet, že obě předpony jsou blíž oblasti USA – východ než USA – západ, a proto směruje uživatele z obou poboček přes okruh ExpressRoute v oblasti USA – východ. Nakonec máte mnoho nešťastných uživatelů v kanceláři Los Angeles.
Řešení: Použití komunit protokolu BGP
Abyste optimalizovali směrování pro uživatele obou poboček, musíte vědět, která předpona je z oblasti Azure USA – západ a která z Azure USA – východ. Tyto informace kódujeme pomocí hodnot komunity protokolu BGP. Pro každou oblast Azure jsme přiřadili jedinečnou hodnotu komunity protokolu BGP, například 12076:51004 usa – východ 12076:51006 pro USA – západ. Teď, když už víte, které předpona je z které oblasti Azure, můžete nakonfigurovat, který okruh ExpressRoute se bude upřednostňovat. Vzhledem k tomu, že k výměně informací o směrování používáme protokol BGP, můžete k ovlivnění směrování použít místní předvolbu protokolu BGP.
V našem příkladu můžete přiřadit vyšší hodnotu Local Preference pro 13.100.0.0/16 v oblasti USA – západ než v oblasti USA – východ a obdobně vyšší hodnotu Local Preference pro 23.100.0.0/16 v oblasti USA – východ než USA – západ. Tato konfigurace zajišťuje, že když jsou k dispozici obě cesty k Microsoftu, uživatelé v Los Angeles převezmou okruh ExpressRoute v oblasti USA – západ, aby se připojili k Azure USA – západ, zatímco vaši uživatelé v New Yorku převezmou ExpressRoute v oblasti USA – východ do Azure USA – východ. Směrování je optimalizované na obou stranách.
Poznámka:
Stejnou techniku pomocí místní předvolby je možné použít pro směrování ze zákazníka do virtuální sítě Azure při použití privátního partnerského vztahu. Microsoft neoznačí hodnoty komunity protokolu BGP k předponám inzerovaným z Azure do vaší sítě. Vzhledem k tomu, že víte, která z vašich virtuálních sítí je nasazení v blízkosti vaší kanceláře, můžete směrovače odpovídajícím způsobem nakonfigurovat tak, aby preferovali jeden okruh ExpressRoute před jiným.
Neoptimální směrování od Microsoftu k zákazníkovi
V tomto příkladu máme připojení od Microsoftu delší cestu k vaší síti. V tomto případě používáte místní servery Exchange a Exchange Online v hybridním prostředí. Vaše pobočky jsou připojené k síti WAN. Inzerujete předpony místních serverů v obou pobočkách Microsoftu prostřednictvím dvou okruhů ExpressRoute.
Exchange Online inicializuje připojení k místním serverům v případech, jako je migrace poštovní schránky. Připojení k vaší kanceláři v Los Angeles je směrováno na okruh ExpressRoute v oblasti USA – východ před přechodem celého kontinentu zpět na západní pobřeží. Příčina problému je podobná té předchozí. Bez jakékoli nápovědy nemůže síť Microsoftu zjistit, která místní předpona je blízko USA – východ a která je blízko usa – západ. Tak se stane, že se pro pobočku v Los Angeles zvolí špatná cesta.
Řešení: Použití předřazení AS PATH
Existují dvě řešení problému. První je, že jednoduše inzerujete místní předponu pro vaši kancelář v Los Angeles 177.2.0.0/31 v okruhu ExpressRoute v oblasti USA – západ. Pak inzerujete místní předponu pro vaši kancelář v New Yorku 177.2.0.2/31 v okruhu ExpressRoute v oblasti USA – východ. V důsledku toho existuje pouze jedna cesta, kterou microsoft může připojit ke každé z vašich poboček. Neexistuje žádná nejednoznačnost a směrování je optimalizované. V tomto návrhu je potřeba se zamyslet nad strategií převzetí služeb při selhání. Pokud cesta k Microsoftu přes ExpressRoute klesne, musíte se ujistit, že se Exchange Online může stále připojovat k vašim místním serverům.
Druhým řešením je, že budete nadále inzerovat obě předpony v obou okruzích ExpressRoute a kromě toho nám dáte vědět, která předpona je blíž ke které z poboček. Protože podporujeme předřazení protokolu BGP AS PATH, můžete konfigurovat cestu AS PATH pro vaši předponu a ovlivnit směrování. V tomto příkladu můžete prodloužit cestu AS PATH pro 172.2.0.0/31 v oblasti USA – východ, abychom preferovali okruh ExpressRoute v oblasti USA – západ pro provoz určený pro tuto předponu. Podobně můžete prodloužit cestu AS PATH pro 172.2.0.2/31 v oblasti USA – západ, abychom preferili okruh ExpressRoute v oblasti USA – východ. Směrování je optimalizované pro obě pobočky. Pokud v tomto návrhu jeden okruh ExpressRoute není funkční, Exchange Online se s vámi pořád může spojit prostřednictvím jiného okruhu ExpressRoute a vaší sítě WAN.
Důležité
Privátní čísla AS odebereme v AS PATH pro předpony přijaté v partnerském vztahu Microsoftu při použití privátního čísla AS. Pokud chcete ovlivnit směrování pro partnerský vztah Microsoftu, musíte vytvořit partnerský vztah s veřejným as a připojit veřejná čísla AS v AS PATH.
Poznámka:
I když jsou zde uvedené příklady pro partnerský vztah Microsoftu, podporujeme stejné možnosti pro privátní partnerský vztah. Předřazení AS PATH navíc funguje v rámci jednoho okruhu ExpressRoute a tak ovlivňuje výběr primární a sekundární cesty.
Neoptimální směrování mezi virtuálními sítěmi
Pomocí ExpressRoute můžete povolit komunikaci mezi dvěma virtuálními sítěmi jejich propojením k okruhu ExpressRoute. Pokud je propojíte k více okruhům ExpressRoute, mezi virtuálními sítěmi může dojít k neoptimálnímu směrování. Zvažte následující příklad. Máte dva okruhy ExpressRoute, jeden v oblasti USA – západ a druhý v oblasti USA – východ. V každé oblasti máte dvě virtuální sítě. Webové servery jsou nasazené v jedné virtuální síti a aplikační servery v druhé. Kvůli redundanci propojíte dvě virtuální sítě v každé oblasti k místnímu okruhu ExpressRoute i ke vzdálenému okruhu ExpressRoute. Jak je vidět v následujícím diagramu, z každé virtuální sítě existují dvě cesty k druhé virtuální síti. Virtuální sítě nevědí, který okruh ExpressRoute je místní a který je vzdálený. Vzhledem k tomu, že směrování ECMP (Equal-Cost-Multi-Path) se používá k vyrovnávání zatížení provozu mezi virtuálními sítěmi, některé toky provozu zabírají delší cestu a směrují se na vzdáleném okruhu ExpressRoute.
Řešení: Přiřazení vysoké váhy místnímu připojení
Řešení je jednoduché. Protože víte, kde se virtuální sítě a obvody nacházejí, můžete nám říct, kterou cestu má každá virtuální síť preferovat. Speciálně v tomto příkladu přiřaďte vyšší váhu místnímu připojení před vzdáleným připojením (viz příklad konfigurace). Když virtuální síť obdrží předponu druhé virtuální sítě na více připojeních, dává přednost připojení s nejvyšší váhou pro odesílání provozu určeného pro danou předponu.
Poznámka:
Směrování z virtuální sítě do místní sítě můžete také ovlivnit, pokud máte více okruhů ExpressRoute, a to tak, že místo použití předběžného nastavení AS PATH nakonfigurujete váhu připojení. Je to technika popsaná ve druhém scénáři. Pro každou předponu se při rozhodování o způsobu odeslání provozu vždy podíváme na váhy připojení dřív, než na délku cesty AS PATH.
Další kroky
- Přečtěte si o návrhu ExpressRoute pro zajištění vysoké dostupnosti.
- Přečtěte si o návrhu ExpressRoute pro zotavení po havárii.