Designöverväganden för Azure VMware Solution-nätverk

Azure VMware Solution erbjuder en privat VMware-molnmiljö som användare och program kan komma åt från lokala och Azure-baserade miljöer eller resurser. Nätverkstjänster som Azure ExpressRoute- och VPN-anslutningar (virtual private network) levererar anslutningen.

Det finns flera nätverksöverväganden att granska innan du konfigurerar din Azure VMware Solution-miljö. Den här artikeln innehåller lösningar för användningsfall som du kan stöta på när du använder Azure VMware Solution för att konfigurera dina nätverk.

Azure VMware Solution-kompatibilitet med AS-Path Prepend

Azure VMware Solution har överväganden som rör användningen av AS-Path Prepend för redundanta ExpressRoute-konfigurationer. Om du kör två eller flera ExpressRoute-sökvägar mellan lokalt och Azure bör du överväga följande vägledning för att påverka trafiken från Azure VMware Solution mot din lokala plats via ExpressRoute GlobalReach.

På grund av asymmetrisk routning kan anslutningsproblem uppstå när Azure VMware Solution inte observerar AS-Path Prepend och därför använder ECMP-routning (equal-cost multipath) för att skicka trafik till din miljö via båda ExpressRoute-kretsarna. Det här beteendet kan orsaka problem med tillståndskänsliga brandväggskontrollenheter som placeras bakom befintliga ExpressRoute-kretsar.

Förutsättningar

För AS-Path Prepend bör du tänka på följande förutsättningar:

• Det viktigaste är att du måste förbereda offentliga ASN-nummer för att påverka hur Azure VMware Solution dirigerar trafiken tillbaka till den lokala miljön. Om du förbereder med privat ASN ignorerar Azure VMware Solution prepend och ECMP-beteendet som nämnts tidigare kommer att inträffa. Även om du använder ett privat BGP ASN lokalt är det fortfarande möjligt att konfigurera dina lokala enheter för att använda ett offentligt ASN när du väntar på utgående vägar för att säkerställa kompatibilitet med Azure VMware Solution.
• Utforma din trafiksökväg för privata ASN:er efter det offentliga ASN som ska respekteras av Azure VMware Solution. Azure VMware Solution ExpressRoute-kretsen tar inte bort några privata ASN som finns i sökvägen efter att det offentliga ASN har bearbetats.
• Båda eller alla kretsar är anslutna till Azure VMware Solution via Azure ExpressRoute Global Reach.
• Samma netblock annonseras från två eller flera kretsar.
• Du vill använda AS-Path Prepend för att tvinga Azure VMware-lösningen att föredra en krets framför en annan.
• Använd antingen offentliga ASN-nummer med 2 byte eller 4 byte.

Hantera virtuella datorer och standardvägar lokalt

Viktigt!

Virtuella Azure VMware Solution Management-datorer (VM) följer inte en standardväg lokalt för RFC1918 mål.

Om du dirigerar tillbaka till dina lokala nätverk med hjälp av endast en standardväg som annonseras mot Azure, kommer trafik från virtuella VCenter Server- och NSX Manager-datorer som används till lokala mål med privata IP-adresser inte att följa den vägen.

Om du vill nå vCenter Server och NSX Manager lokalt tillhandahåller du specifika vägar för att tillåta trafik att ha en retursökväg till dessa nätverk. Annonsera till exempel RFC1918 sammanfattningar (10.0.0.0/8, 172.16.0.0/12 och 192.168.0.0/16).

Standardväg till Azure VMware Solution för internettrafikkontroll

Vissa distributioner kräver att all utgående trafik från Azure VMware Solution inspekteras mot Internet. Även om det är möjligt att skapa virtuella nätverksinstallationer (NVA) i Azure VMware Solution finns det användningsfall där dessa apparater redan finns i Azure och kan användas för att inspektera Internettrafik från Azure VMware Solution. I det här fallet kan en standardväg matas in från NVA i Azure för att locka trafik från Azure VMware Solution och inspektera trafiken innan den går ut till det offentliga Internet.

I följande diagram beskrivs en grundläggande hub-and-spoke-topologi som är ansluten till ett Azure VMware Solution-moln och till ett lokalt nätverk via ExpressRoute. Diagrammet visar hur NVA i Azure kommer från standardvägen (0.0.0.0/0). Azure Route Server sprider vägen till Azure VMware Solution via ExpressRoute.

Viktigt!

Standardvägen som NVA annonserar sprids till det lokala nätverket. Du måste lägga till användardefinierade vägar (UDR) för att säkerställa att trafik från Azure VMware Solution överförs via NVA.

Kommunikation mellan Azure VMware Solution och det lokala nätverket sker vanligtvis via ExpressRoute Global Reach, enligt beskrivningen i Peer-lokala miljöer till Azure VMware Solution.

Anslut mellan Azure VMware Solution och ett lokalt nätverk

Det finns två huvudsakliga scenarier för anslutning mellan Azure VMware Solution och ett lokalt nätverk via en nva från tredje part:

• Organisationer har ett krav på att skicka trafik mellan Azure VMware Solution och det lokala nätverket via en NVA (vanligtvis en brandvägg).
• ExpressRoute Global Reach är inte tillgängligt i en viss region för att ansluta ExpressRoute-kretsarna i Azure VMware Solution och det lokala nätverket.

Det finns två topologier som du kan tillämpa för att uppfylla alla krav för dessa scenarier: virtuellt nätverk med supernät och transiteker.

Viktigt!

Det bästa alternativet för att ansluta Azure VMware Solution och lokala miljöer är en direkt ExpressRoute Global Reach-anslutning. Mönstren som beskrivs i den här artikeln lägger till komplexitet i miljön.

Designtopologi för Supernet

Om båda ExpressRoute-kretsarna (till Azure VMware Solution och lokalt) avslutas i samma ExpressRoute-gateway kan du anta att gatewayen kommer att dirigera paket över dem. En ExpressRoute-gateway är dock inte utformad för att göra det. Du måste hårpina trafiken till en NVA som kan dirigera trafiken.

Det finns två krav för hårnålsnätverkstrafik till en NVA:

• NVA bör annonsera ett supernät för Azure VMware Solution och lokala prefix.

  Du kan använda ett supernät som innehåller både Azure VMware Solution och lokala prefix. Eller så kan du använda enskilda prefix för Azure VMware Solution och lokalt (alltid mindre specifika än de faktiska prefix som annonseras via ExpressRoute). Tänk på att alla supernätprefix som annonseras till Route Server sprids till både Azure VMware Solution och lokalt.

• UDR:er i gatewayundernätet, som exakt matchar prefixen som annonseras från Azure VMware Solution och lokalt, orsakar hårnålstrafik från gateway-undernätet till NVA.

Den här topologin resulterar i höga hanteringskostnader för stora nätverk som ändras över tid. Tänk på dessa begränsningar:

• Varje gång ett arbetsbelastningssegment skapas i Azure VMware Solution kan UDF:er behöva läggas till för att säkerställa att trafik från Azure VMware Solution överförs via NVA.
• Om din lokala miljö har ett stort antal vägar som ändras kan BGP-konfigurationen (Border Gateway Protocol) och UDR-konfigurationen i supernätet behöva uppdateras.
• Eftersom en enskild ExpressRoute-gateway bearbetar nätverkstrafik i båda riktningarna kan prestandan vara begränsad.
• Det finns en azure virtual network-gräns på 400 UDR.

Följande diagram visar hur NVA behöver annonsera prefix som är mer generiska (mindre specifika) och som inkluderar nätverken från den lokala lösningen och Azure VMware Solution. Var försiktig med den här metoden. NVA kan potentiellt locka trafik som den inte borde, eftersom den annonserar bredare intervall (till exempel hela 10.0.0.0/8 nätverket).

Överföringstopologi för virtuellt nätverk

Kommentar

Om reklamprefix som är mindre specifika inte är möjliga på grund av de tidigare beskrivna gränserna kan du implementera en alternativ design som använder två separata virtuella nätverk.

I den här topologin, i stället för att sprida vägar som är mindre specifika för att locka trafik till ExpressRoute-gatewayen, kan två olika NVA:er i separata virtuella nätverk utbyta vägar mellan varandra. De virtuella nätverken kan sprida dessa vägar till sina respektive ExpressRoute-kretsar via BGP och Azure Route Server. Varje NVA har fullständig kontroll över vilka prefix som sprids till varje ExpressRoute-krets.

Följande diagram visar hur en enda 0.0.0.0/0 väg annonseras till Azure VMware Solution. Den visar också hur de enskilda Azure VMware Solution-prefixen sprids till det lokala nätverket.

Viktigt!

Ett inkapslingsprotokoll som VXLAN eller IPsec krävs mellan nva:erna. Inkapsling krävs eftersom NVA-nätverkskortet (NIC) skulle lära sig vägarna från Azure Route Server med NVA som nästa hopp och skapa en routningsloop.

Det finns ett alternativ till att använda ett överlägg. Använd sekundära nätverkskort i NVA som inte lär sig vägarna från Azure Route Server. Konfigurera sedan UDR så att Azure kan dirigera trafik till fjärrmiljön över dessa nätverkskort. Mer information finns i Nätverkstopologi och anslutning i företagsskala för Azure VMware Solution.

Den här topologin kräver en komplex inledande konfiguration. Topologin fungerar sedan som förväntat med minimala hanteringskostnader. Konfigurationskomplexiteter omfattar:

• Det finns en extra kostnad för att lägga till ett annat virtuellt transitnätverk som inkluderar Azure Route Server, en ExpressRoute-gateway och en annan NVA. NVA:erna kan också behöva använda stora VM-storlekar för att uppfylla dataflödeskraven.
• IPsec- eller VXLAN-tunnlar krävs mellan de två NVA:erna, vilket innebär att NVA:erna också finns i datasökvägen. Beroende på vilken typ av NVA du använder kan det resultera i anpassad och komplex konfiguration på dessa NVA:er.

Nästa steg

När du har lärt dig mer om nätverksdesignöverväganden för Azure VMware Solution kan du utforska följande artiklar:

• Nätverks- och sammanlänkningskoncept för Azure VMware Solution
• Planera distributionen av Azure VMware Solution
• Självstudie: Checklista för nätverksplanering för Azure VMware Solution