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 VNets som är anslutna direkt (VNets 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.

All VNet and branch connections are associated and propagating to the default route table. Ä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 Routing Intent. Mer information finns i Så här konfigurerar du routnings- och routningsprinciper för Virtual WAN Hub.

Omedelbart utbyter Virtual WAN-hubbar information sinsemellan så att kommunikationen mellan regioner möjliggörs. 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 rutter kommer sedan att annonseras av Virtual WAN till filialer och integreras i de virtuella nätverken som är anslutna till de virtuella hubbarna, vilket gör att användningen av användardefinierade rutter blir 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 "Anslutning till virtuellt nätverk" anger till exempel att prefixet definieras i ett virtuellt nätverk som är direkt anslutet till Virtual WAN (VNet 11 och 12 i föregående skärmbild)

The NVA in VNet 12 injects the route 10.1.20.0/22 over BGP, as the Next Hop Type "HubBgpConnection" implies (see BGP Peering with a Virtual Hub). This summary route covers both indirect spokes VNet 121 (10.1.21.0/24) and VNet 122 (10.1.22.0/24). VNets and branches in the remote hub are visible with a next hop of hub2, and it can be seen in the AS path that the Autonomous System Number 65520 has been prepended two times to these interhub routes.

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. Note that the route to the SDWAN branch 10.5.3.0/24 has a next hop of VPN_S2S_Gateway. This type of next hop can indicate today either routes coming from an Azure Virtual Network Gateway or from NVAs integrated in the hub.

In hub 2, the route for 10.2.20.0/22 to the indirect spokes VNet 221 (10.2.21.0/24) and VNet 222 (10.2.22.0/24) is installed as a static route, as indicated by the origin defaultRouteTable. Om du kontrollerar de effektiva rutterna för hubb 1, finns den rutten inte 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 rutt i hubb 1 för att tillhandahålla anslutning mellan de virtuella nätverken och grenarna i hubb 1 till de indirekta förgreningarna i hubb 2 (VNet 221 och 222).

After adding the static route, hub 1 will contain the 10.2.20.0/22 route as well:

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. Denna topologi stöds av routingintention. Mer information finns i Så här konfigurerar du routnings- och routningsprinciper för Virtual WAN Hub.

Som förklaras i Virtual hub routing preference gynnar Virtual WAN rutter från ExpressRoute som 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:

As you can see in the routes, ExpressRoute Global Reach prepends the ExpressRoute Autonomous System Number (12076) multiple times before sending routes back to Azure to make these routes less preferable. However, Virtual WAN default hub routing precedence of ExpressRoute ignores the AS path length when taking routing decision.

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.

Med en hubbdirigeringsinställning för VPN ser de effektiva vägarna i hubb 1 ut så här:

The previous image shows that the route to 10.4.2.0/24 has now a next hop of VPN_S2S_Gateway, while with the default routing preference of ExpressRoute it was ExpressRouteGateway. However, in hub 2 the route to 10.5.2.0/24 will still appear with a next hop of ExpressRoute, because in this case the alternative route doesn't come from a VPN Gateway but from an NVA integrated in the hub:

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.

Now the routes for remote spokes and branches in hub 1 will have a next hop of Remote Hub as intended:

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 rutter som annonseras via VPN har en kortare AS-sökväg än de rutter som annonseras via ExpressRoute. After configuring the on-premises VPN device to prepend its Autonomous System Number (65501) to the VPN routes to make the less preferable, hub 1 now selects ExpressRoute as next hop for 10.4.2.0/24:

Hub 2 will show a similar table for the effective routes, where the VNets and branches in the other hub now appear with Remote Hub as next hop:

Scenario 3: Korsanslutning av ExpressRoute-kretsarna till båda hubbarna

In order to add direct links between the Azure regions and the on-premises locations connected via ExpressRoute, it's often desirable connecting a single ExpressRoute circuit to multiple Virtual WAN hubs in a topology some times described as "bow tie", as the following topology shows:

Viktigt!

I föregående diagram visas två säkra virtuella hubbar. Denna topologi stöds av routingintention. 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:

Genom att återgå till standardpreferensen för hubbdirigering för ExpressRoute, kommer vägarna till fjärrgrenar och virtuella nätverk i hubb 1 återigen att visa ExpressRoute som nästa hopp. Även om orsaken den här gången inte är Global Reach, utan det faktum att ExpressRoute-kretsarna skickar tillbaka de routingsannonser som de tar emot från en hubb till en annan. For example, the effective routes of hub 1 with hub routing preference of ExpressRoute are as follows:

Changing back the hub routing preference again to AS Path returns the inter hub routes to the optimal path using the direct connection between hubs 1 and 2:

Nästa steg

Mer information om Virtual WAN finns i:

• Vanliga frågor och svar om Virtual WAN