Nätverk i flera regioner med Azure Route Server
Program med höga krav på hög tillgänglighet eller haveriberedskap måste ofta distribueras i mer än en Azure-region. I sådana fall måste virtuella ekernätverk (VNet) i olika regioner kommunicera med varandra. Ett sätt att aktivera den här kommunikationen är genom att peer-koppla alla nödvändiga virtuella ekernätverk till varandra. Den här metoden kringgår dock alla virtuella nätverksinstallationer (NVA) som brandväggar i hubbarna. Ett alternativ är att använda användardefinierade vägar (UDR) i de undernät där hubb-NVA:er distribueras, men det kan vara svårt att underhålla UDR:er. Azure Route Server erbjuder ett dynamiskt alternativ som anpassas till topologiändringar automatiskt, utan att manuella åtgärder krävs.
Topologi
Följande diagram visar en arkitektur med dubbla regioner, där en hubb- och ekertopologi finns i varje region, och de virtuella hubbnätverken peerkopplas till varandra via global peering för virtuella nätverk:
NVA i varje region lär sig prefixen för de lokala hubb- och eker-VNet:erna via Azure Route Server och delar dem med NVA i den andra regionen med BGP. För att undvika routningsloopar är det viktigt att upprätta den här kommunikationen mellan nva:erna med hjälp av en inkapslingsteknik som IPsec eller VXtensible LAN (VXLAN).
Om du vill göra det möjligt för Azure Route Server att annonsera prefixen för de virtuella ekernätverken till de lokala NVA:erna och mata in de inlärda vägarna i de virtuella ekernätverken igen, är det viktigt att använda inställningen Använd fjärrvirt virtuellt nätverks gateway eller Routningsserver för peering mellan de virtuella ekernätverken och det virtuella hubbnätverket.
NVA:erna annonserar de vägar som de lär sig från fjärrregionen till sin lokala routningsserver, som sedan konfigurerar dessa vägar i de lokala virtuella ekernätverken och drar till sig trafik i enlighet därmed. I de fall där flera NVA:er finns i samma region (Routningsserver stöder upp till åtta BGP-peer-datorer) kan AS-sökvägen användas för att göra en av de NVA:er som föredras framför de andra, vilket effektivt etablerar en aktiv/standby NVA-topologi.
Viktigt!
För att säkerställa att den lokala routningsservern kan lära sig de vägar som annonseras av NVA från fjärrregionen måste NVA ta bort det autonoma systemnumret (ASN) 65515 från AS-sökvägen för vägarna. Den här tekniken kallas ibland för "AS-åsidosättning" eller "AS-sökvägsomskrivning" på vissa BGP-plattformar. Annars hindrar BGP-loopskyddsmekanismen den lokala routningsservern från att lära sig dessa vägar eftersom den förbjuder inlärning av vägar som redan innehåller det lokala ASN.
ExpressRoute
Designen för flera regioner kan kombineras med ExpressRoute- eller VPN-gatewayer. Följande diagram visar en topologi, inklusive en ExpressRoute-gateway som är ansluten till ett lokalt nätverk i en av Azure-regionerna. I det här fallet hjälper ett överläggsnätverk över ExpressRoute-kretsen till att förenkla nätverket, så att lokala prefix endast visas i Azure som annonseras av NVA (och inte från ExpressRoute-gatewayen).
Designa utan överlägg
Tunnlarna mellan regioner mellan nva:erna krävs eftersom en routningsloop annars bildas. Om du till exempel tittar på NVA i region 1:
- NVA i region 1 lär sig prefixen från region 2 och annonserar dem till routningsservern i region 1.
- Routningsservern i region 1 matar in vägar för dessa prefix i alla undernät i region 1, med NVA i region 1 som nästa hopp.
- För trafik från region 1 till region 2, när NVA i region 1 skickar trafik till den andra NVA, ärver dess eget undernät samt de vägar som programmeras av routningsservern, som pekar på sig själv (NVA). Så paketet returneras till NVA och en routningsloop visas.
Om UDR:er är ett alternativ kan du inaktivera BGP-vägspridning i NVA:ernas undernät och konfigurera statiska UDR:er i stället för ett överlägg, så att Azure kan dirigera trafik till de virtuella fjärr ekernätverken.