Djupdykning i Virtual WAN-routning
Azure Virtual WAN är en nätverkslösning som gör det enkelt att skapa avancerade nätverkstopologier: det omfattar routning mellan Azure-regioner mellan virtuella Azure-nätverk och lokala platser via punkt-till-plats-VPN, plats-till-plats-VPN, ExpressRoute och integrerade SDWAN-apparater, inklusive alternativet för att skydda trafiken. I de flesta scenarier krävs det inte att du har djup kunskap om hur intern routning i Virtual WAN fungerar, men i vissa situationer kan det vara användbart att förstå begrepp för Virtual WAN-routning.
Det här dokumentet utforskar exempel på Virtual WAN-scenarier som förklarar några av de beteenden som organisationer kan stöta på när de ansluter sina virtuella nätverk och grenar i komplexa nätverk. Scenarierna som visas i den här artikeln är inte på något sätt designrekommendationer, de är bara exempeltopologier som är utformade för att demonstrera vissa Virtual WAN-funktioner.
Scenario 1: topologi med standardinställning för routning
Det första scenariot i den här artikeln analyserar en topologi med två Virtual WAN-hubbar, ExpressRoute, VPN och SDWAN-anslutning. I varje hubb finns det virtuella nätverk som är anslutna direkt (VNet 11 och 21) och indirekt via en NVA (VNets 121, 122, 221 och 222). VNet 12 utbyter routningsinformation med hubb 1 via BGP (se BGP-peering med en virtuell hubb) och VNet 22 har statiska vägar konfigurerade, så att skillnader mellan båda alternativen kan visas.
I varje hubb har VPN- och SDWAN-enheterna ett dubbelt syfte: på ena sidan annonserar de sina egna individuella prefix (10.4.1.0/24 via VPN i hubb 1 och 10.5.3.0/24 över SDWAN i hubb 2), och å andra sidan annonserar de samma prefix som ExpressRoute-kretsarna i samma region (10.4.2.0/24 i hubb 1 och 10.5.2.0/24 i hubb 2). Den här skillnaden används för att visa hur routningsinställningen för Virtual WAN-hubben fungerar.
Alla VNet- och grenanslutningar är associerade och sprids till standardroutningstabellen. Även om hubbarna är skyddade (det finns en Azure Firewall distribuerad i varje hubb) är de inte konfigurerade för att skydda privat trafik eller Internettrafik. Detta skulle leda till att alla anslutningar sprids till routningstabellen None , vilket skulle ta bort alla icke-statiska vägar från routningstabellen Default och motverka syftet med den här artikeln eftersom det effektiva vägbladet i portalen skulle vara nästan tomt (förutom de statiska vägarna för att skicka trafik till Azure Firewall).
Viktigt!
I föregående diagram visas två säkra virtuella hubbar. Den här topologin stöds med routnings avsikt. Mer information finns i Så här konfigurerar du routnings- och routningsprinciper för Virtual WAN Hub.
Ut ur rutan utbyter Virtual WAN-hubbar information mellan varandra så att kommunikationen mellan regioner är aktiverad. Du kan inspektera de effektiva vägarna i Virtual WAN-routningstabeller: följande bild visar till exempel de effektiva vägarna i hubb 1:
Dessa effektiva vägar annonseras sedan av Virtual WAN till grenar och matar in dem i de virtuella nätverk som är anslutna till de virtuella hubbarna, vilket gör användningen av användardefinierade vägar onödig. När du inspekterar de effektiva vägarna i en virtuell hubb anger fälten "Nästa hopptyp" och "Ursprung" var vägarna kommer ifrån. En Next Hop-typ av "Virtual Network Anslut ion" anger till exempel att prefixet definieras i ett virtuellt nätverk som är direkt anslutet till Virtual WAN (VNets 11 och 12 i föregående skärmbild)
NVA i VNet 12 matar in vägen 10.1.20.0/22 över BGP, som nästa hopptyp "HubBgp Anslut ion" antyder (se BGP-peering med en virtuell hubb). Den här sammanfattningsvägen omfattar både indirekta ekrar VNet 121 (10.1.21.0/24) och VNet 122 (10.1.22.0/24). Virtuella nätverk och grenar i fjärrhubben visas med nästa hopp av hub2, och det kan ses i AS-sökvägen att det autonoma systemnumret 65520 har förberetts två gånger till dessa interhub-vägar.
I hubb 2 finns en integrerad virtuell SDWAN-nätverksinstallation. Mer information om NVA:er som stöds för den här integreringen finns i Om NVA:er i en Virtual WAN-hubb. Observera att vägen till SDWAN-grenen 10.5.3.0/24 har nästa hopp på VPN_S2S_Gateway. Den här typen av nästa hopp kan i dag ange antingen vägar som kommer från en Azure Virtual Network Gateway eller från NVA:er som är integrerade i hubben.
I hubb 2 installeras vägen för 10.2.20.0/22 till de indirekta ekrarna VNet 221 (10.2.21.0/24) och VNet 222 (10.2.22.0/24) som en statisk väg, enligt ursprunget defaultRouteTable. Om du checkar in de effektiva vägarna för hubb 1 finns inte den vägen där. Orsaken är att statiska vägar inte sprids via BGP, utan måste konfigureras i varje hubb. Därför krävs en statisk väg i hubb 1 för att tillhandahålla anslutning mellan de virtuella nätverken och grenarna i hubb 1 till de indirekta ekrarna i hubb 2 (VNet 221 och 222):
När du har lagt till den statiska vägen innehåller 10.2.20.0/22 hubb 1 även vägen:
Scenario 2: Inställningar för global räckvidd och hubbroutning
Även om hub 1 känner till ExpressRoute-prefixet från krets 2 (10.5.2.0/24) och hubb 2 känner till ExpressRoute-prefixet från krets 1 (10.4.2.0/24), annonseras inte ExpressRoute-vägar från fjärranslutna regioner tillbaka till lokala ExpressRoute-länkar. Därför krävs ExpressRoute Global Reach för att ExpressRoute-platserna ska kunna kommunicera med varandra:
Viktigt!
I föregående diagram visas två säkra virtuella hubbar. Den här topologin stöds med routnings avsikt. Mer information finns i Så här konfigurerar du routnings- och routningsprinciper för Virtual WAN Hub.
Som förklaras i routningsinställningen för virtuell hubb föredrar Virtual WAN vägar som kommer från ExpressRoute per standard. Eftersom vägar annonseras från hubb 1 till ExpressRoute-kretsen 1, från ExpressRoute-kretsen 1 till kretsen 2 och från ExpressRoute-kretsen 2 till hubb 2 (och vice versa), föredrar virtuella hubbar den här vägen framför den mer direkta interhubblänken nu. De effektiva vägarna i hubb 1 visar följande:
Som du kan se i vägarna förbereder ExpressRoute Global Reach ExpressRoute Autonomous System Number (12076) flera gånger innan du skickar vägar tillbaka till Azure för att göra dessa vägar mindre föredragna. Standarddirigeringsprioriteten för Virtual WAN-hubb i ExpressRoute ignorerar dock längden på AS-sökvägen när du tar routningsbeslut.
De effektiva vägarna i hubb 2 kommer att se ut ungefär så här:
Routningsinställningen kan ändras till VPN eller AS-Path enligt beskrivningen i Routningsinställningen för virtuell hubb. Du kan till exempel ställa in inställningen på VPN enligt följande bild:
Med en hubbdirigeringsinställning för VPN ser de effektiva vägarna i hubb 1 ut så här:
Den föregående bilden visar att vägen till 10.4.2.0/24 nu har ett nästa hopp på VPN_S2S_Gateway, medan den med standardinställningen för routning för ExpressRoute var ExpressRouteGateway. I hubb 2 visas vägen till 10.5.2.0/24 fortfarande med nästa hopp på ExpressRoute, eftersom den alternativa vägen i det här fallet inte kommer från en VPN Gateway utan från en NVA som är integrerad i hubben:
Trafik mellan hubbar föredrar dock fortfarande de vägar som kommer via ExpressRoute. Om du vill använda den effektivare direktanslutningen mellan de virtuella hubbarna kan routningsinställningen anges till "AS Path" på båda hubbarna:
Nu har vägarna för fjärranslutna ekrar och grenar i hubb 1 ett nästa hopp på Remote Hub som avsett:
Du kan se att IP-prefixet för hubb 2 (192.168.2.0/23) fortfarande kan nås via länken Global Räckvidd, men detta bör inte påverka trafiken eftersom det inte bör finnas någon trafik riktad till enheter i hubb 2. Den här vägen kan dock vara ett problem om det fanns NVA:er i båda hubbarna som upprättade SDWAN-tunnlar mellan varandra.
Observera dock att 10.4.2.0/24 nu föredras framför VPN Gateway. Detta kan inträffa om de vägar som annonseras via VPN har en kortare AS-sökväg än de vägar som annonseras via ExpressRoute. När du har konfigurerat den lokala VPN-enheten så att den förbereder sitt autonoma systemnummer (65501) till VPN-vägarna för att göra det mindre att föredra väljer hubb 1 nu ExpressRoute som nästa hopp för 10.4.2.0/24:
Hub 2 visar en liknande tabell för de effektiva vägarna, där de virtuella nätverken och grenarna i den andra hubben nu visas som Remote Hub nästa hopp:
Scenario 3: Korsanslutning av ExpressRoute-kretsarna till båda hubbarna
För att lägga till direkta länkar mellan Azure-regionerna och de lokala platser som är anslutna via ExpressRoute är det ofta önskvärt att ansluta en enda ExpressRoute-krets till flera Virtual WAN-hubbar i en topologi vissa gånger som beskrivs som "fluga", som följande topologi visar:
Viktigt!
I föregående diagram visas två säkra virtuella hubbar. Den här topologin stöds med routnings avsikt. Mer information finns i Så här konfigurerar du routnings- och routningsprinciper för Virtual WAN Hub.
Virtual WAN visar att båda kretsarna är anslutna till båda hubbarna:
Om du går tillbaka till standardinställningen för hubbdirigering för ExpressRoute visas vägarna till fjärrgrenar och virtuella nätverk i hubb 1 igen ExpressRoute som nästa hopp. Även om orsaken den här gången inte är Global Reach, utan det faktum att ExpressRoute-kretsarna studsar tillbaka de vägannonser som de får från en hubb till en annan. Till exempel är de effektiva vägarna för hubb 1 med hubbdirigeringsinställning för ExpressRoute följande:
Om du ändrar tillbaka hubbdirigeringsinställningen igen till AS Path returneras inter hubbvägarna till den optimala sökvägen med hjälp av direktanslutningen mellan hubbar 1 och 2:
Nästa steg
Mer information om Virtual WAN finns i: