Vanliga frågor om Virtual WAN
Är Azure Virtual WAN i GA?
Ja, Azure Virtual WAN är allmänt tillgängligt (GA). Virtual WAN består dock av flera funktioner och scenarier. Det finns funktioner eller scenarier i Virtual WAN där Microsoft tillämpar förhandsgranskningstaggen. I dessa fall finns den specifika funktionen, eller själva scenariot, i förhandsversion. Om du inte använder en specifik förhandsversionsfunktion gäller vanlig GA-support. Mer information om förhandsversionsstöd finns i Kompletterande användningsvillkor för Förhandsversioner av Microsoft Azure.
Vilka platser och regioner är tillgängliga?
Information om hur du visar tillgängliga regioner för Virtual WAN finns i Produkter som är tillgängliga per region. Ange Virtual WAN som produktnamn.
Behöver användaren ha hubb och eker med SD-WAN/VPN-enheter för att använda Azure Virtual WAN?
Virtual WAN har många funktioner som är inbyggda i en enda fönsterruta, till exempel plats-till-plats-VPN-anslutning, Användar-/P2S-anslutning, ExpressRoute-anslutning, virtuell nätverksanslutning, VPN ExpressRoute Interconnectivity, transitiv anslutning mellan virtuella nätverk, centraliserad routning, Säkerhet i Azure Firewall och Firewall Manager, övervakning, ExpressRoute-kryptering och många andra funktioner. Du behöver inte ha alla dessa användningsfall för att börja använda Virtual WAN. Du kan komma igång med bara ett användningsfall.
Virtual WAN-arkitekturen är en nav- och ekerarkitektur med skalning och prestanda inbyggda där grenar (VPN/SD-WAN-enheter), användare (Azure VPN-klienter, openVPN- eller IKEv2-klienter), ExpressRoute-kretsar, virtuella nätverk fungerar som ekrar till virtuella hubbar. Alla hubbar är anslutna i fullständigt nät i ett Standard Virtual WAN, vilket gör det enkelt för användaren att använda Microsofts stamnät för alla-till-alla-anslutningar (alla ekrar). För hubb och eker med SD-WAN/VPN-enheter kan användarna antingen konfigurera det manuellt i Azure Virtual WAN-portalen eller använda Virtual WAN Partner CPE (SD-WAN/VPN) för att konfigurera anslutningen till Azure.
Virtual WAN-partner tillhandahåller automatisering för anslutningar, vilket är möjligheten att exportera enhetsinformationen till Azure, ladda ned Azure-konfigurationen och upprätta anslutning till Azure Virtual WAN-hubben. För punkt-till-plats-/användar-VPN-anslutning stöder vi Azure VPN-klienten, OpenVPN- eller IKEv2-klienten.
Kan du inaktivera fullständigt nätade hubbar i ett virtuellt WAN?
Virtual WAN finns i två varianter: Basic och Standard. I Basic Virtual WAN är hubbarna inte sammankopplade. I ett Standard Virtual WAN kopplas hubbar ihop och ansluts automatiskt när det virtuella WAN-nätverket först konfigureras. Användaren behöver inte göra något specifikt. Användaren behöver inte heller inaktivera eller aktivera funktionen för att hämta näthubbar. Virtual WAN ger dig många routningsalternativ för att styra trafik mellan alla ekrar (VNet, VPN eller ExpressRoute). Det gör det enkelt att använda helt nätade hubbar och även flexibiliteten att dirigera trafik efter dina behov.
Hur hanteras Tillgänglighetszoner och återhämtning i Virtual WAN?
Virtual WAN är en samling hubbar och tjänster som görs tillgängliga i hubben. Användaren kan ha så många Virtual WAN-nätverk som de behöver. I en Virtual WAN-hubb finns det flera tjänster som VPN, ExpressRoute osv. Var och en av dessa tjänster distribueras automatiskt över Tillgänglighetszoner (förutom Azure Firewall), om regionen stöder Tillgänglighetszoner. Om en region blir en tillgänglighetszon efter den första distributionen i hubben kan användaren återskapa gatewayerna, vilket utlöser en distribution i tillgänglighetszonen. Alla gatewayer etableras i en hubb som aktiv-aktiv, vilket innebär att det finns inbyggd återhämtning i en hubb. Användare kan ansluta till flera hubbar om de vill ha återhämtning mellan regioner.
För närvarande kan Azure Firewall distribueras för att stödja Tillgänglighetszoner med hjälp av Azure Firewall Manager-portalen, PowerShell eller CLI. Det finns för närvarande inget sätt att konfigurera en befintlig brandvägg som ska distribueras mellan tillgänglighetszoner. Du måste ta bort och distribuera om azure-brandväggen.
Även om begreppet Virtual WAN är globalt är den faktiska Virtual WAN-resursen Resource Manager-baserad och distribuerad regionalt. Om själva den virtuella WAN-regionen skulle ha ett problem fortsätter alla hubbar i det virtuella WAN-nätverket att fungera som de är, men användaren kommer inte att kunna skapa nya hubbar förrän den virtuella WAN-regionen är tillgänglig.
Går det att dela brandväggen i en skyddad hubb med andra hubbar?
Nej, varje Virtuell Azure-hubb måste ha en egen brandvägg. Distributionen av anpassade vägar för att peka brandväggen för en annan skyddad hubb misslyckas och slutförs inte. Överväg att konvertera dessa hubbar till skyddade hubbar med sina egna brandväggar.
Vilken klient stöder Azure Virtual WAN-användar-VPN (punkt-till-plats) ?
Virtual WAN stöder Azure VPN-klient, OpenVPN-klient eller valfri IKEv2-klient. Microsoft Entra-autentisering stöds med Azure VPN-klienten. Minst Windows 10-klientoperativsystem version 17763.0 eller senare krävs. OpenVPN-klienter kan stödja certifikatbaserad autentisering. När cert-baserad autentisering har valts på gatewayen visas filen.ovpn* som ska laddas ned till enheten. IKEv2 stöder både certifikat- och RADIUS-autentisering.
För användar-VPN (punkt-till-plats)– varför är P2S-klientpoolen uppdelad i två vägar?
Varje gateway har två instanser. Delningen sker så att varje gatewayinstans oberoende kan allokera klient-IP-adresser för anslutna klienter och trafik från det virtuella nätverket dirigeras tillbaka till rätt gatewayinstans för att undvika instanshopp mellan gatewayer.
Hur gör jag för att lägga till DNS-servrar för P2S-klienter?
Det finns två alternativ för att lägga till DNS-servrar för P2S-klienterna. Den första metoden föredras eftersom den lägger till anpassade DNS-servrar till gatewayen i stället för klienten.
Använd följande PowerShell-skript för att lägga till anpassade DNS-servrar. Ersätt värdena för din miljö.
// Define variables $rgName = "testRG1" $virtualHubName = "virtualHub1" $P2SvpnGatewayName = "testP2SVpnGateway1" $vpnClientAddressSpaces = $vpnServerConfiguration1Name = "vpnServerConfig1" $vpnClientAddressSpaces = New-Object string[] 2 $vpnClientAddressSpaces[0] = "192.168.2.0/24" $vpnClientAddressSpaces[1] = "192.168.3.0/24" $customDnsServers = New-Object string[] 2 $customDnsServers[0] = "7.7.7.7" $customDnsServers[1] = "8.8.8.8" $virtualHub = $virtualHub = Get-AzVirtualHub -ResourceGroupName $rgName -Name $virtualHubName $vpnServerConfig1 = Get-AzVpnServerConfiguration -ResourceGroupName $rgName -Name $vpnServerConfiguration1Name // Specify custom dns servers for P2SVpnGateway VirtualHub while creating gateway createdP2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName $rgname -Name $P2SvpnGatewayName -VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig1 -CustomDnsServer $customDnsServers // Specify custom dns servers for P2SVpnGateway VirtualHub while updating existing gateway $P2SVpnGateway = Get-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName $updatedP2SVpnGateway = Update-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName -CustomDnsServer $customDnsServers // Re-generate Vpn profile either from PS/Portal for Vpn clients to have the specified dns serversOm du använder Azure VPN-klienten för Windows 10 kan du ändra den nedladdade PROFIL-XML-filen och lägga till <taggarna dnsservers><dnsserver<>/dnsserver></dnsservers> innan du importerar den.
<azvpnprofile> <clientconfig> <dnsservers> <dnsserver>x.x.x.x</dnsserver> <dnsserver>y.y.y.y</dnsserver> </dnsservers> </clientconfig> </azvpnprofile>
För användar-VPN (punkt-till-plats) – Hur många klienter stöds?
Tabellen nedan beskriver antalet samtidiga anslutningar och aggregerat dataflöde för punkt-till-plats-VPN-gatewayen som stöds i olika skalningsenheter.
| Skalningsenhet | Gatewayinstanser | Samtidiga anslutningar som stöds | Aggregerat dataflöde |
|---|---|---|---|
| 1 | 2 | 500 | 0,5 Gbit/s |
| 2 | 2 | 500 | 1 Gbit/s |
| 3 | 2 | 500 | 1,5 Gbit/s |
| 4 | 2 | 1000 | 2 Gbit/s |
| 5 | 2 | 1000 | 2,5 Gbit/s |
| 6 | 2 | 1000 | 3 Gbit/s |
| 7 | 2 | 5000 | 3,5 Gbit/s |
| 8 | 2 | 5000 | 4 Gbit/s |
| 9 | 2 | 5000 | 4,5 Gbit/s |
| 10 | 2 | 5000 | 5 Gbit/s |
| 11 | 2 | 10000 | 5,5 Gbit/s |
| 12 | 2 | 10000 | 6 Gbit/s |
| 13 | 2 | 10000 | 6,5 Gbit/s |
| 14 | 2 | 10000 | 7 Gbit/s |
| 15 | 2 | 10000 | 7,5 Gbit/s |
| 16 | 2 | 10000 | 8 Gbit/s |
| 17 | 2 | 10000 | 8,5 Gbit/s |
| 18 | 2 | 10000 | 9 Gbit/s |
| 19 | 2 | 10000 | 9,5 Gbit/s |
| 20 | 2 | 10000 | 10 Gbit/s |
| 40 | 4 | 20000 | 20 Gbit/s |
| 60 | 6 | 30000 | 30 Gbit/s |
| 80 | 8 | 40000 | 40 Gbit/s |
| 100 | 10 | 50000 | 50 Gbit/s |
| 120 | 12 | 60000 | 60 Gbit/s |
| 140 | 14 | 70000 | 70 Gbit/s |
| 160 | 16 | 80000 | 80 Gbit/s |
| 180 | 18 | 90000 | 90 Gbit/s |
| 200 | 20 | 100000 | 100 Gbit/s |
Anta till exempel att användaren väljer en skalningsenhet. Varje skalningsenhet skulle innebära att en aktiv-aktiv gateway distribueras och var och en av instanserna (i det här fallet 2) skulle ha stöd för upp till 500 anslutningar. Eftersom du kan få 500 anslutningar * 2 per gateway betyder det inte att du planerar för 1 000 i stället för 500 för den här skalningsenheten. Instanser kan behöva betjänas under vilka anslutningen för de extra 500 kan avbrytas om du överskrider det rekommenderade antalet anslutningar.
För gatewayer med skalningsenheter som är större än 20 distribueras ytterligare gateway-par med hög tillgänglighet för att ge ytterligare kapacitet för att ansluta användare. Varje par med instanser stöder upp till 10 000 ytterligare användare. Om du till exempel distribuerar en gateway med 100 skalningsenheter distribueras 5 gatewaypar (totalt 10 instanser) och upp till 50 000 (10 000 användare x 5 gatewaypar) samtidiga användare kan ansluta.
Se också till att planera för stilleståndstid om du bestämmer dig för att skala upp eller ned på skalningsenheten eller ändra punkt-till-plats-konfigurationen på VPN-gatewayen.
För Användar-VPN (punkt-till-plats) stöds Microsoft-registrerad app i Entra ID-autentisering?
Ja, Microsoft-registrerad app stöds på Virtual WAN. Du kan migrera ditt användar-VPN från manuellt registrerad app till Microsoft-registrerad app för en säkrare anslutning.
Vad är Virtual WAN Gateway-skalningsenheter?
En skalningsenhet är en enhet som definierats för att välja ett aggregerat dataflöde för en gateway i virtuell hubb. 1 skalningsenhet för VPN = 500 Mbit/s. 1 skalningsenhet för ExpressRoute = 2 Gbit/s. Exempel: 10 skalningsenhet för VPN skulle innebära 500 Mbit/s * 10 = 5 Gbit/s.
Vad är skillnaden mellan en virtuell Azure-nätverksgateway (VPN Gateway) och en Azure Virtual WAN VPN-gateway?
Virtual WAN tillhandahåller storskalig plats-till-plats-anslutning och byggs för dataflöde, skalbarhet och användarvänlighet. När du ansluter en plats till en Virtuell WAN VPN-gateway skiljer det sig från en vanlig virtuell nätverksgateway som använder en gatewaytyp "plats-till-plats VPN". När du vill ansluta fjärranvändare till Virtual WAN använder du gatewaytypen "punkt-till-plats-VPN". VPN-gatewayerna punkt-till-plats och plats-till-plats är separata entiteter i Virtual WAN-hubben och måste distribueras individuellt. När du ansluter en ExpressRoute-krets till en Virtuell WAN-hubb använder den på samma sätt en annan resurs för ExpressRoute-gatewayen än den vanliga virtuella nätverksgatewayen som använder gatewaytypen ExpressRoute.
Virtual WAN stöder upp till 20 Gbit/s aggregerat dataflöde både för VPN och ExpressRoute. Virtual WAN har också automatisering för anslutning med ett ekosystem av CPE-grenenhetspartners. CPE-grenenheter har inbyggd automatisering som automatiskt etablerar och ansluter till Azure Virtual WAN. Enheterna finns tillgängliga från ett växande ekosystem av SD-WAN- och VPN-partner. Se listan Föredragen partner.
Hur skiljer sig Virtual WAN från en virtuell Azure-nätverksgateway?
Vpn för en virtuell nätverksgateway är begränsad till 100 tunnlar. För anslutningar bör du använda Virtual WAN för ett storskaligt virtuellt privat nätverk. Du kan ansluta upp till 1 000 grenanslutningar per virtuell hubb med en mängd på 20 Gbit/s per hubb. En anslutning är en aktiv-aktiv-tunnel från den lokala VPN-enheten till den virtuella hubben. Du kan också ha flera virtuella hubbar per region, vilket innebär att du kan ansluta mer än 1 000 grenar till en enda Azure-region genom att distribuera flera Virtual WAN-hubbar i den Azure-regionen, var och en med sin egen VPN-gateway från plats till plats.
Vilken är den rekommenderade algoritmen och paketen per sekund per plats-till-plats-instans i Virtual WAN-hubben? Hur många tunnlar stöds per instans? Vilket maximalt dataflöde stöds i en enda tunnel?
Virtual WAN stöder 2 aktiva VPN-gatewayinstanser från plats till plats i en virtuell hubb. Det innebär att det finns två aktiva-aktiva uppsättning VPN-gatewayinstanser i en virtuell hubb. Under underhållsåtgärder uppgraderas varje instans en efter en på grund av att en användare kan uppleva en kort minskning av aggregerat dataflöde för en VPN-gateway.
Virtual WAN VPN stöder många algoritmer, men vår rekommendation är GCMAES256 för både IPSEC-kryptering och integritet för optimala prestanda. AES256 och SHA256 anses vara mindre högpresterande och därför kan prestandaförsämring som svarstid och paketförluster förväntas för liknande algoritmtyper.
Paket per sekund eller PPS är en faktor för det totala antalet paket och det dataflöde som stöds per instans. Detta förstås bäst med ett exempel. Låt oss säga att en vpn-gatewayinstans med en skalningsenhet på 500 Mbit/s distribueras i en virtuell WAN-hubb. Om vi antar en paketstorlek på 1 400 förväntas PPS för vpn-gatewayinstansen högst = [(500 Mbit/s * 1024 * 1024) /8/1400] ~ 47000.
Virtual WAN har begrepp om VPN-anslutning, länkanslutning och tunnlar. En enda VPN-anslutning består av länkanslutningar. Virtual WAN stöder upp till 4 länkanslutningar i en VPN-anslutning. Varje länkanslutning består av två IPsec-tunnlar som avslutas i två instanser av en aktiv-aktiv VPN-gateway som distribueras i en virtuell hubb. Det totala antalet tunnlar som kan avslutas i en enda aktiv instans är 1 000, vilket också innebär att dataflödet för 1 instans kommer att vara tillgängligt aggregerat över alla tunnlar som ansluter till den instansen. Varje tunnel har också vissa dataflödesvärden. Om flera tunnlar är anslutna till en enhetsgateway med lägre värde är det bäst att utvärdera behovet per tunnel och planera för en VPN-gateway som är ett aggregerat värde för dataflöde i alla tunnlar som avslutas i VPN-instansen.
Värden för olika skalningsenheter som stöds i Virtual WAN
| Skalningsenhet | Maximalt dataflöde per tunnel (Mbit/s) | Maximalt antal PPS per tunnel | Maximalt dataflöde per instans (Mbit/s) | Max PPS per instans |
|---|---|---|---|---|
| 1 | 500 | 47 000 | 500 | 47 000 |
| 2 | 1000 | 94 000 | 1000 | 94 000 |
| 3 | 1500 | 140 000 | 1500 | 140 000 |
| 4 | 1500 | 140 000 | 2000 | 187 000 |
| 5 | 1500 | 140 000 | 2500 | 234 K |
| 6 | 1500 | 140 000 | 3000 | 281 000 |
| 7 | 2 300 | 215 K | 3500 | 328 K |
| 8 | 2 300 | 215 K | 4000 | 374 K |
| 9 | 2 300 | 215 K | 4 500 | 421K |
| 10 | 2 300 | 215 K | 5000 | 468 K |
| 11 | 2 300 | 215 K | 5 500 | 515 K |
| 12 | 2 300 | 215 K | 6000 | 562 K |
| 13 | 2 300 | 215 K | 6 500 | 609K |
| 14 | 2 300 | 215 K | 7000 | 655 K |
| 15 | 2 300 | 215 K | 7 500 | 702 K |
| 16 | 2 300 | 215 K | 8000 | 749 000 |
| 17 | 2 300 | 215 K | 8 500 | 796 K |
| 18 | 2 300 | 215 K | 9 000 | 843 K |
| 19 | 2 300 | 215 K | 9 500 | 889 K |
| 20 | 2 300 | 215 K | 10000 | 936K |
Kommentar
Alla tal baseras på GCM-algoritmen.
Vilka enhetsprovidrar (Virtual WAN-partner) stöds?
Just nu stöds den helt automatiserade Virtual WAN-upplevelsen av många partner. Mer information finns i Virtual WAN-partner.
Vilka är automatiseringsstegen för virtuella WAN-partner?
Information om automatiseringssteg för partner finns i avsnittet om automatisering för virtuella WAN-partner.
Måste jag använda en önskad partnerenhet?
Nej. Du kan använda valfri VPN-kompatibel enhet som följer Azure-kraven för IKEv2/IKEv1 IPsec-stöd. Virtual WAN har även CPE-partnerlösningar som automatiserar anslutningen till Azure Virtual WAN, vilket gör det enklare att konfigurera IPsec VPN-anslutningar i stor skala.
Hur automatiserar Virtual WAN-partner anslutningsmöjligheter med Azure Virtual WAN?
Programvarudefinierade anslutningslösningar hanterar vanligtvis gren-enheter med hjälp av en kontrollant eller ett enhetsetableringscenter. Kontrollanten kan automatisera anslutningar till Azure Virtual WAN med hjälp av Azure API:er. Automatiseringen omfattar uppladdning av greninformation, nedladdning av Azure-konfigurationen, konfiguration av IPsec-tunnlar till Azure Virtual Hubs och automatisk konfiguration av anslutning från grenenheten till Azure Virtual WAN. När du har hundratals grenar är det enkelt att ansluta med hjälp av Virtual WAN CPE-partner eftersom registreringsupplevelsen tar bort behovet av att konfigurera, konfigurera och hantera storskaligA IPsec-anslutningar. Läs mer i informationen om automatisering för virtuell WAN-partner.
Vad händer om en enhet jag använder inte finns med i listan med Virtual WAN-partner? Kan jag fortfarande använda den för att ansluta till Azure Virtual WAN VPN?
Ja så länge enheten stöder IPsec IKEv1 eller IKEv2. Virtual WAN-partner automatiserar anslutningen från enheten till Azure VPN-slutpunkter. Detta innebär automatiserade steg som "överföring av greninformation", "IPsec och konfiguration" och "anslutning". Eftersom enheten inte kommer från ett Virtual WAN-partnerekosystem måste du göra det tunga arbetet med att manuellt ta Azure-konfigurationen och uppdatera enheten för att konfigurera IPsec-anslutning.
Hur registreras nya partner som inte finns med i startpartnerlistan?
Alla virtuella WAN-API:er är OpenAPI. Du kan gå över dokumentationen för virtual WAN-partnerautomatisering för att utvärdera teknisk genomförbarhet. En perfekt partner är en partner som har en enhet som kan etableras för IKEv1 eller IKEv2 IPSec-anslutning. När företaget har slutfört automationsarbetet för sin CPE-enhet baserat på riktlinjerna för automatisering som anges ovan kan du kontakta för att azurevirtualwan@microsoft.com visas här Anslutning via partner. Om du är en kund som vill att en viss företagslösning ska listas som en Virtual WAN-partner ska företaget kontakta Virtual WAN genom att skicka ett e-postmeddelande till azurevirtualwan@microsoft.com.
Hur stöder Virtual WAN SD-WAN-enheter?
Virtual WAN-partner automatiserar IPsec-anslutningen till Azure VPN-slutpunkter. Om Virtual WAN-partnern är en SD-WAN-provider är det underförstått att SD-WAN-styrenheten hanterar automatisering och IPsec-anslutning till Azure VPN-slutpunkter. Om SD-WAN-enheten kräver en egen slutpunkt i stället för Azure VPN för någon egen SD-WAN-funktion kan du distribuera SD-WAN-slutpunkten i ett virtuellt Azure-nätverk och samexistera med Azure Virtual WAN.
Virtual WAN stöder BGP-peering och har även möjlighet att distribuera NVA:er till en virtuell WAN-hubb.
Hur många VPN-enheter kan ansluta till en enda hubb?
Upp till 1 000 anslutningar stöds per virtuell hubb. Varje anslutning består av fyra länkar och varje länkanslutning stöder två tunnlar som är i en aktiv-aktiv konfiguration. Tunnlarna avslutas i en VPN-gateway för virtuell Azure-hubb. Länkar representerar den fysiska ISP-länken på grenen/VPN-enheten.
Vad är en grenanslutning till Azure Virtual WAN?
En anslutning från en gren eller VPN-enhet till Azure Virtual WAN är en VPN-anslutning som ansluter praktiskt taget VPN-platsen och Azure VPN-gatewayen i en virtuell hubb.
Vad händer om den lokala VPN-enheten bara har en tunnel till en Azure Virtual WAN VPN-gateway?
En Azure Virtual WAN-anslutning består av två tunnlar. En VIRTUAL WAN VPN-gateway distribueras i en virtuell hubb i aktivt-aktivt läge, vilket innebär att det finns separata tunnlar från lokala enheter som avslutas på separata instanser. Det här är rekommendationen för alla användare. Men om användaren väljer att bara ha en tunnel till en av vpn-gatewayinstanserna för Virtuellt WAN, om gatewayinstansen av någon anledning (underhåll, korrigeringar osv.) tas offline, flyttas tunneln till den sekundära aktiva instansen och användaren kan uppleva en återanslutning. BGP-sessioner flyttas inte mellan instanser.
Vad händer under en gatewayåterställning i en Virtual WAN VPN-gateway?
Knappen Gatewayåterställning bör användas om alla lokala enheter fungerar som förväntat, men VPN-anslutningen för plats-till-plats i Azure är i frånkopplat tillstånd. Virtuella WAN VPN-gatewayer distribueras alltid i ett aktivt-aktivt tillstånd för hög tillgänglighet. Det innebär att det alltid finns fler än en instans distribuerad i en VPN-gateway när som helst. När knappen Gateway-återställning används startar den om instanserna i VPN-gatewayen på ett sekventiellt sätt så att dina anslutningar inte störs. Det kommer att finnas en kort lucka när anslutningar flyttas från en instans till en annan, men det här gapet bör vara mindre än en minut. Observera dessutom att återställningen av gatewayerna inte ändrar dina offentliga IP-adresser.
Det här scenariot gäller endast för S2S-anslutningarna.
Kan den lokala VPN-enheten ansluta till flera hubbar?
Ja. Trafikflödet kommer från den lokala enheten till närmaste Microsoft-nätverksgräns och sedan till den virtuella hubben.
Finns nya Resource Manager-resurser tillgängliga för Virtual WAN?
Ja, Virtual WAN har nya Resource Manager-resurser. Mer information finns i Översikt.
Kan jag distribuera och använda min favoritnätverksinstallation (i ett virtuellt NVA-nätverk) med Azure Virtual WAN?
Ja, du kan ansluta ditt virtuella nätverksinstallationsnätverk (NVA) till Azure Virtual WAN.
Kan jag skapa en virtuell nätverksinstallation i den virtuella hubben?
En virtuell nätverksinstallation (NVA) kan distribueras i en virtuell hubb. Anvisningar finns i Om NVA:er i en Virtual WAN-hubb.
Kan ett virtuellt ekernätverk ha en virtuell nätverksgateway?
Nej. Det virtuella ekernätverket kan inte ha en virtuell nätverksgateway om det är anslutet till den virtuella hubben.
Kan ett virtuellt ekernätverk ha en Azure Route Server?
Nej. Det virtuella ekernätverket kan inte ha en routningsserver om det är anslutet till den virtuella WAN-hubben.
Finns det stöd för BGP i VPN-anslutning?
Ja, BGP stöds. När du skapar en VPN-plats kan du ange BGP-parametrarna i den. Detta innebär att alla anslutningar som skapats i Azure för den platsen kommer att aktiveras för BGP.
Finns det licens- eller prisinformation om Virtual WAN?
Ja. Se sidan med prissättning.
Är det möjligt att konstruera Azure Virtual WAN med en Resource Manager-mall?
En enkel konfiguration av ett virtuellt WAN med en hubb och en vpnsite kan skapas med hjälp av en snabbstartsmall. Virtual WAN är främst en REST- eller portaldriven tjänst.
Kan virtuella ekernätverk som är anslutna till en virtuell hubb kommunicera med varandra (V2V-överföring)?
Ja. Standard Virtual WAN stöder transitiv anslutning mellan virtuella nätverk via den virtuella WAN-hubb som de virtuella nätverken är anslutna till. I Virtual WAN-terminologi refererar vi till dessa sökvägar som "lokal virtuell WAN VNet-överföring" för virtuella nätverk som är anslutna till en Virtuell WAN-hubb inom en enda region och "global virtuell WAN VNet-överföring" för virtuella nätverk som är anslutna via flera Virtual WAN-hubbar i två eller flera regioner.
I vissa scenarier kan virtuella ekernätverk också peerkopplas direkt med varandra med hjälp av peering för virtuella nätverk utöver lokal eller global virtuell WAN VNet-överföring. I det här fallet har VNet-peering företräde framför den transitiva anslutningen via Virtual WAN-hubben.
Tillåts gren-till-gren-anslutningar i Virtual WAN?
Ja, det finns stöd för gren-till-gren-anslutningar i Virtual WAN. Grenen är konceptuellt tillämplig på VPN-platser, ExpressRoute-kretsar eller punkt-till-plats-/användares VPN-användare. Aktivering av gren-till-gren är aktiverat som standard och kan finnas i WAN-konfigurationsinställningarna. På så sätt kan VPN-grenar/-användare ansluta till andra VPN-grenar och överföringsanslutningen aktiveras också mellan VPN- och ExpressRoute-användare.
Passerar förgrenings-till-gren-trafik via Azure Virtual WAN?
Ja. Förgrenings-till-gren-trafik passerar genom Azure Virtual WAN.
Kräver Virtual WAN ExpressRoute från varje plats?
Nej. Virtual WAN kräver inte ExpressRoute från varje plats. Dina webbplatser kan vara anslutna till ett providernätverk med hjälp av en ExpressRoute-krets. För webbplatser som är anslutna med ExpressRoute till en virtuell hubb och IPsec VPN till samma hubb tillhandahåller den virtuella hubben överföringsanslutning mellan VPN- och ExpressRoute-användaren.
Finns det ett nätverksdataflöde eller en anslutningsgräns när du använder Azure Virtual WAN?
Nätverksdataflödet är per tjänst i en virtuell WAN-hubb. I varje hubb är VPN-aggregerat dataflöde upp till 20 Gbit/s, expressroute-aggregerat dataflöde är upp till 20 Gbit/s och det sammanlagda vpn-dataflödet för användare/punkt-till-plats är upp till 200 Gbit/s. Routern i den virtuella hubben stöder upp till 50 Gbit/s för VNet-till-VNet-trafikflöden och förutsätter totalt 2 000 VM-arbetsbelastningar för alla virtuella nätverk som är anslutna till en enda virtuell hubb.
Om du vill skydda startkapaciteten utan att behöva vänta på att den virtuella hubben ska skalas ut när mer dataflöde behövs kan du ange minsta kapacitet eller ändra efter behov. Se Om inställningar för virtuell hubb – hubbkapacitet. Information om kostnadskonsekvenser finns i Kostnaden för routningsinfrastrukturenhet på sidan Prissättning för Azure Virtual WAN.
När VPN-webbplatser ansluter till en hubb gör de det med anslutningar. Virtual WAN stöder upp till 1 000 anslutningar eller 2 000 IPsec-tunnlar per virtuell hubb. När fjärranvändare ansluter till en virtuell hubb ansluter de till P2S VPN-gatewayen, som stöder upp till 100 000 användare beroende på vilken skalningsenhet(bandbredd) som valts för P2S VPN-gatewayen i den virtuella hubben.
Kan jag använda NAT-T på mina VPN-anslutningar?
Ja, NAT-bläddering (NAT-T) stöds. Virtual WAN VPN-gatewayen utför INTE några NAT-liknande funktioner på de inre paketen till/från IPsec-tunnlarna. I den här konfigurationen kontrollerar du att den lokala enheten initierar IPsec-tunneln.
Hur konfigurerar jag en skalningsenhet till en specifik inställning som 20 Gbit/s?
Gå till VPN-gatewayen i en hubb på portalen och klicka sedan på skalningsenheten för att ändra den till rätt inställning.
Tillåter Virtual WAN att den lokala enheten använder flera internetleverantörer parallellt, eller är det alltid en enda VPN-tunnel?
Lokala enhetslösningar kan tillämpa trafikprinciper för att styra trafik över flera tunnlar till Azure Virtual WAN-hubben (VPN-gateway i den virtuella hubben).
Vad är global transitarkitektur?
Mer information finns i Global transitnätverksarkitektur och Virtual WAN.
Hur dirigeras trafiken i Azures stamnät?
Trafiken följer mönstret: grenenhet -ISP-Microsoft network edge-Microsoft> DC (hub VNet)->Microsoft network edge-ISP-branch>> device>>
Vad behöver du på varje plats i den här modellen? Bara en Internetanslutning?
Ja. En internetanslutning och fysisk enhet som stöder IPsec, helst från våra integrerade Virtual WAN-partner. Du kan också hantera konfigurationen och anslutningen till Azure manuellt från önskad enhet.
Hur gör jag för att aktivera standardvägen (0.0.0.0/0) för en anslutning (VPN, ExpressRoute eller virtuellt nätverk)?
En virtuell hubb kan sprida en inlärd standardväg till ett virtuellt nätverk/plats-till-plats-VPN/ExpressRoute-anslutning om flaggan är "Aktiverad" på anslutningen. Den här flaggan visas när användaren redigerar en virtuell nätverksanslutning, en VPN-anslutning eller en ExpressRoute-anslutning. Som standard inaktiveras den här flaggan när en plats eller en ExpressRoute-krets är ansluten till en hubb. Den aktiveras som standard när en virtuell nätverksanslutning läggs till för att ansluta ett virtuellt nätverk till en virtuell hubb.
Standardvägen har inte sitt ursprung i Virtual WAN-hubben. Standardvägen sprids om den redan har lärts av Virtual WAN-hubben som ett resultat av att en brandvägg distribueras i hubben, eller om en annan ansluten plats har aktiverat tvingad tunneltrafik. En standardväg sprids inte mellan hubbar (mellan hubbar).
Går det att skapa flera virtuella WAN-hubbar i samma region?
Ja. Kunder kan nu skapa fler än en hubb i samma region för samma Azure Virtual WAN.
Hur väljer den virtuella hubben i ett virtuellt WAN den bästa vägen för en väg från flera hubbar?
Mer information finns på inställningssidan för routning av virtuell hubb.
Tillåter Virtual WAN-hubben anslutning mellan ExpressRoute-kretsar?
Överföring mellan ER-till-ER sker alltid via global räckvidd. Virtuella hubbgatewayer distribueras i DC- eller Azure-regioner. När två ExpressRoute-kretsar ansluter via Global räckvidd behöver trafiken inte komma hela vägen från gränsroutrarna till den virtuella hubbens domänkontrollant.
Finns det ett begrepp om vikt i Azure Virtual WAN ExpressRoute-kretsar eller VPN-anslutningar
När flera ExpressRoute-kretsar är anslutna till en virtuell hubb ger routningsvikt på anslutningen en mekanism för ExpressRoute i den virtuella hubben att föredra en krets framför den andra. Det finns ingen mekanism för att ange en vikt på en VPN-anslutning. Azure föredrar alltid en ExpressRoute-anslutning framför en VPN-anslutning i en enda hubb.
Föredrar Virtual WAN ExpressRoute framför VPN för utgående trafik i Azure
Ja. Virtual WAN föredrar ExpressRoute framför VPN för trafik som utgående Azure. Du kan dock konfigurera routningsinställningen för virtuell hubb för att ändra standardinställningen. Anvisningar finns i Konfigurera routningsinställningar för virtuell hubb.
Vad skulle göra att en VPN-anslutningsväg föredras framför ExpressRoute när en Virtuell WAN-hubb har en ExpressRoute-krets och en VPN-plats ansluten till den?
När en ExpressRoute-krets är ansluten till en virtuell hubb är Microsoft Edge-routrarna den första noden för kommunikation mellan lokalt och Azure. Dessa gränsroutrar kommunicerar med Virtual WAN ExpressRoute-gatewayerna som i sin tur lär sig vägar från den virtuella hubbroutern som styr alla vägar mellan alla gatewayer i Virtual WAN. Microsoft Edge-routrarna bearbetar ExpressRoute-vägar för virtuell hubb med högre prioritet jämfört med vägar som lärts in lokalt.
Om VPN-anslutningen av någon anledning blir det primära mediet för den virtuella hubben att lära sig vägar från (t.ex. redundansscenarier mellan ExpressRoute och VPN), såvida inte VPN-platsen har en längre AS Path-längd, fortsätter den virtuella hubben att dela VPN-inlärda vägar med ExpressRoute-gatewayen. Detta gör att Microsoft Edge-routrarna föredrar VPN-vägar framför lokala vägar.
Stöder ExpressRoute ECMP-routning (Equal-Cost Multi-Path) i Virtual WAN?
När flera ExpressRoute-kretsar är anslutna till en Virtuell WAN-hubb gör ECMP att trafik från virtuella ekernätverk till lokala nätverk via ExpressRoute kan distribueras över alla ExpressRoute-kretsar som annonserar samma lokala vägar. ECMP är för närvarande inte aktiverat som standard för Virtual WAN-hubbar.
När två hubbar (hubb 1 och 2) är anslutna och det finns en ExpressRoute-krets ansluten som en fluga till båda hubbarna, vad är sökvägen för ett VNet som är anslutet till hubb 1 för att nå ett VNet som är anslutet i hubb 2?
Det aktuella beteendet är att föredra ExpressRoute-kretssökvägen framför hubb-till-hubb för VNet-till-VNet-anslutning. Detta rekommenderas dock inte i en Virtual WAN-konfiguration. För att lösa detta kan du göra en av två saker:
Konfigurera flera ExpressRoute-kretsar (olika leverantörer) för att ansluta till en hubb och använda hubb-till-hub-anslutningen som tillhandahålls av Virtual WAN för trafikflöden mellan regioner.
Konfigurera AS-Path som hubbdirigeringsinställning för din virtuella hubb. Detta säkerställer att trafiken mellan de två hubbarna passerar via den virtuella hubbroutern i varje hubb och använder hubb-till-hubb-sökvägen i stället för ExpressRoute-sökvägen (som passerar genom Microsoft Edge-routrarna). Mer information finns i Konfigurera routningsinställningen för en virtuell hubb.
När det finns en ExpressRoute-krets som är ansluten som en fluga till en Virtual WAN-hubb och ett fristående virtuellt nätverk, vilken är vägen för det fristående virtuella nätverket att nå Virtual WAN-hubben?
För nya distributioner blockeras den här anslutningen som standard. Om du vill tillåta den här anslutningen kan du aktivera dessa ExpressRoute-gatewayväxlingar på bladet "Redigera virtuell hubb" och "Virtuell nätverksgateway" i portalen. Vi rekommenderar dock att du inaktiverar dessa växlingsknappar och i stället skapar en virtuell nätverksanslutning för att ansluta fristående virtuella nätverk direkt till en Virtual WAN-hubb. Därefter passerar VNet-till-VNet-trafik via virtual WAN-hubbens router, vilket ger bättre prestanda än ExpressRoute-sökvägen. ExpressRoute-sökvägen innehåller ExpressRoute-gatewayen, som har lägre bandbreddsgränser än hubbroutern, samt Microsoft Enterprise Edge-routrar/MSEE, vilket är ett extra hopp i datasökvägen.
I diagrammet nedan måste båda växlarna aktiveras för att tillåta anslutning mellan det fristående virtuella nätverket 4 och de virtuella nätverk som är direkt anslutna till hubb 2 (VNet 2 och VNet 3): Tillåt trafik från fjärranslutna Virtual WAN-nätverk för den virtuella nätverksgatewayen och Tillåt trafik från icke-virtuella WAN-nätverk för den virtuella hubbens ExpressRoute-gateway. Om en Azure Route Server distribueras i fristående VNet 4 och routningsservern har branch-to-branch aktiverat blockeras anslutningen mellan VNet 1 och fristående VNet 4.
Om du aktiverar eller inaktiverar växlingsknappen påverkas endast följande trafikflöde: trafik som flödar mellan virtual WAN-hubben och fristående virtuella nätverk via ExpressRoute-kretsen. Aktivering eller inaktivering av växlingsknappen medför inte stilleståndstid för alla andra trafikflöden (t.ex. påverkas inte den lokala platsen till eker-VNet 2, VNet 2 till VNet 3 påverkas inte osv.).
Kan hubbar skapas i olika resursgrupper i Virtual WAN?
Ja. Det här alternativet är för närvarande endast tillgängligt via PowerShell. Virtual WAN-portalen kräver att hubbarna finns i samma resursgrupp som själva Virtual WAN-resursen.
Vilket är det rekommenderade hubbadressutrymmet när hubben skapas?
Det rekommenderade adressutrymmet för Virtual WAN-hubben är /23. Virtual WAN Hub tilldelar undernät till olika gatewayer (ExpressRoute, plats-till-plats-VPN, punkt-till-plats-VPN, Azure Firewall, Virtuell hubbrouter). För scenarier där NVA:er distribueras i en virtuell hubb är en /28 vanligtvis utskuren för NVA-instanserna. Men om användaren skulle etablera flera NVA:er kan ett /27-undernät tilldelas. Därför bör du tänka på en framtida arkitektur, medan Virtual WAN-hubbar distribueras med en minsta storlek på /24, men det rekommenderade hubbadressutrymmet vid skapandetiden för användaren att mata in är /23.
Finns det stöd för IPv6 i Virtual WAN?
IPv6 stöds inte i Virtual WAN-hubben och dess gatewayer. Om du har ett virtuellt nätverk som har stöd för IPv4 och IPv6 och vill ansluta det virtuella nätverket till Virtual WAN stöds inte det här scenariot för närvarande.
För punkt-till-plats-användar-VPN-scenariot med internet-breakout via Azure Firewall måste du förmodligen inaktivera IPv6-anslutningen på klientenheten för att tvinga trafik till Virtual WAN-hubben. Det beror på att moderna enheter som standard använder IPv6-adresser.
Vilken är den rekommenderade API-versionen som ska användas av skript som automatiserar olika Virtual WAN-funktioner?
En lägsta version av 05-01-2022 (1 maj 2022) krävs.
Finns det några Virtual WAN-gränser?
Se avsnittet Virtual WAN-gränser på sidan Prenumerations- och tjänstbegränsningar.
Vilka är skillnaderna mellan Virtual WAN-typerna (Basic och Standard)?
Se Grundläggande och Standard Virtual WAN. Priser finns på sidan Prissättning .
Lagrar Virtual WAN kunddata?
Nej. Virtual WAN lagrar inga kunddata.
Finns det några leverantörer av hanterade tjänster som kan hantera Virtual WAN för användare som en tjänst?
Ja. En lista över MSP-lösningar (Managed Service Provider) som är aktiverade via Azure Marketplace finns i Azure Marketplace-erbjudanden från Azure Networking MSP-partner.
Hur skiljer sig Routning av Virtual WAN-hubbar från Azure Route Server i ett virtuellt nätverk?
Både Azure Virtual WAN Hub och Azure Route Server tillhandahåller peeringfunktioner för Border Gateway Protocol (BGP) som kan användas av NVA:er (Network Virtual Appliance) för att annonsera IP-adresser från NVA till användarens virtuella Azure-nätverk. Distributionsalternativen skiljer sig åt i den meningen att Azure Route Server vanligtvis distribueras av ett självhanterat virtuellt kundhubbnätverk medan Azure Virtual WAN tillhandahåller en helt nätfri hubbtjänst som kunderna ansluter sina olika ekerslutpunkter till (Azure VNet, lokala grenar med plats-till-plats-VPN eller SDWAN, fjärranvändare med punkt-till-plats/VPN för fjärranvändare och privata anslutningar med ExpressRoute) och njuta av BGP-peering för NVA:er som distribuerats i eker-VNet tillsammans med andra vWAN funktioner som överföringsanslutning för VNet-till-VNet, överföringsanslutning mellan VPN och ExpressRoute, anpassad/avancerad routning, anpassad routningsassociation och spridning, routningssyfte/principer utan krångel mellan regioner, Secure Hub/Azure-brandvägg osv. Mer information om BGP-peering för Virtual WAN finns i Så här peerar du BGP med en virtuell hubb.
Om jag använder en tredjepartssäkerhetsprovider (Zscaler, iBoss eller Checkpoint) för att skydda min Internettrafik, varför ser jag inte VPN-platsen som är associerad med tredjepartssäkerhetsprovidern i Azure Portal?
När du väljer att distribuera en säkerhetspartnerleverantör för att skydda Internetåtkomsten för dina användare skapar tredjepartssäkerhetsleverantören en VPN-webbplats åt dig. Eftersom tredjepartssäkerhetsprovidern skapas automatiskt av providern och inte är en användarskapad VPN-webbplats visas inte den här VPN-webbplatsen i Azure Portal.
Mer information om tillgängliga alternativ för tredjepartssäkerhetsleverantörer och hur du konfigurerar detta finns i Distribuera en säkerhetspartnerprovider.
Bevaras BGP-communities som genereras lokalt i Virtual WAN?
Ja, BGP-communities som genereras av lokala kommer att bevaras i Virtual WAN.
Kommer BGP-communities som genereras av BGP-peer-datorer (i ett anslutet virtuellt nätverk) att bevaras i Virtual WAN?
Ja, BGP-communities som genereras av BGP-peer-datorer bevaras i Virtual WAN. Communities bevaras i samma hubb och mellan interhub-anslutningar. Detta gäller även för Virtual WAN-scenarier med hjälp av principer för routnings avsikt.
Vilka ASN-nummer stöds för fjärranslutna lokala nätverk som kör BGP?
Du kan använda dina egna offentliga ASN:er eller privata ASN:er för dina lokala nätverk. Du kan inte använda de intervall som är reserverade av Azure eller IANA:
- ASN reserverade av Azure:
- Offentliga ASN:er: 8074, 8075, 12076
- Privata ASN:er: 65515, 65517, 65518, 65519, 65520
- ASN reserverade av IANA: 23456, 64496-64511, 65535-65551
Finns det något sätt att ändra ASN för en VPN-gateway?
Nej. Virtual WAN stöder inte ASN-ändringar för VPN-gatewayer.
Vilka är uppskattade prestanda för ExpressRoute-gateway-SKU:n i Virtual WAN?
| Skalningsenhet | Anslutningar per sekund | Megabitar per sekund | Paket per sekund |
|---|---|---|---|
| 1 skalningsenhet |
14 000 | 2 000 | 200 000 |
| 2 skalningsenheter |
28,000 | 4 000 | 400,000 |
| 3 skalningsenheter |
42,000 | 6 000 | 600,000 |
| 4 skalningsenheter |
56,000 | 8,000 | 800,000 |
| 5 skalningsenheter |
70,000 | 10 000 | 1,000,000 |
| 6 skalningsenheter |
84,000 | 12 000 | 1,200,000 |
| 7 skalningsenheter |
98,000 | 14 000 | 1,400,000 |
| 8 skalningsenheter |
112,000 | 16 000 | 1,600,000 |
| 9 skalningsenheter |
126,000 | 18 000 | 1,800,000 |
| 10 skalningsenheter |
140,000 | 20 000 | 2,000,000 |
Skalningsenheterna 2–10 underhåller under underhållsåtgärder aggregerat dataflöde. Skalningsenhet 1 kan dock under en underhållsåtgärd se en liten variation i dataflödesnummer.
Kommer jag bara att kunna komma åt regioner på samma tunnelbaneplats som den lokala kretsen om jag ansluter en lokal ExpressRoute-krets till en Virtual WAN-hubb?
Lokala kretsar kan bara anslutas till ExpressRoute-gatewayer i motsvarande Azure-region. Det finns dock ingen begränsning för att dirigera trafik till virtuella ekernätverk i andra regioner.
Varför visas ett meddelande och en knapp med namnet "Uppdatera router till den senaste programvaruversionen" i portalen?
Kommentar
Från och med den 1 juli 2024 dras hubbar på den gamla versionen tillbaka i faser och slutar fungera som förväntat.
Azure-wide Cloud Services-baserad infrastruktur är inaktuell. Därför har Virtual WAN-teamet arbetat med att uppgradera virtuella routrar från sin nuvarande Cloud Services-infrastruktur till vm-skalningsuppsättningar baserade distributioner. Alla nya virtuella hubbar distribueras automatiskt på den senaste vm-skalningsuppsättningar baserade infrastrukturen. Om du navigerar till din Virtual WAN-hubbresurs och ser det här meddelandet och knappen kan du uppgradera routern till den senaste versionen genom att klicka på knappen. Om du vill dra nytta av nya Virtual WAN-funktioner, till exempel BGP-peering med hubben, måste du uppdatera din virtuella hubbrouter via Azure Portal. Om knappen inte visas öppnar du ett supportärende.
Du kan bara uppdatera routern för den virtuella hubben om alla resurser (gatewayer/routningstabeller/VNet-anslutningar) i hubben är i ett lyckat tillstånd. Kontrollera att alla dina virtuella ekernätverk finns i aktiva/aktiverade prenumerationer och att dina virtuella ekernätverk inte tas bort. Eftersom den här åtgärden kräver distribution av nya vm-skalningsuppsättningar baserade på virtuella hubbroutrar får du dessutom en förväntad stilleståndstid på 1–2 minuter för VNet-till-VNet-trafik via samma hubb och 5–7 minuter för alla andra trafikflöden via hubben. Planera ett underhållsperiod på minst 30 minuter eftersom stilleståndstiden kan ta upp till 30 minuter i värsta fall. Inom en enda Virtual WAN-resurs bör hubbar uppdateras en i taget i stället för att uppdatera flera samtidigt. När routerversionen säger "Senaste" är hubben klar med uppdateringen. Det kommer inte att ske några ändringar i routningsbeteendet efter den här uppdateringen.
Det finns flera saker att notera med uppgraderingen av den virtuella hubbens router:
Om du redan har konfigurerat BGP-peering mellan din Virtual WAN-hubb och en NVA i ett virtuellt ekernätverk måste du ta bort och sedan återskapa BGP-peern. Eftersom IP-adresserna för den virtuella hubben ändras efter uppgraderingen måste du också konfigurera om din NVA för att peerkoppla med den virtuella hubbrouterns nya IP-adresser. Dessa IP-adresser representeras som fältet "virtualRouterIps" i den virtuella hubbens resurs-JSON.
Om du har en virtuell nätverksinstallation (NVA) i den virtuella hubben måste du arbeta med din NVA-partner för att få instruktioner om hur du uppgraderar din Virtual WAN-hubb.
Om din virtuella hubb har konfigurerats med fler än 15 routningsinfrastrukturenheter skalar du i din virtuella hubb till 2 routningsinfrastrukturenheter innan du försöker uppgradera. Du kan skala ut hubben till fler än 15 routningsinfrastrukturenheter när du har uppgraderat hubben.
Om uppdateringen misslyckas av någon anledning återställs hubben automatiskt till den gamla versionen för att säkerställa att det fortfarande finns en fungerande konfiguration.
Ytterligare saker att notera:
Användaren måste ha en ägar- eller deltagarroll för att se en korrekt status för hubbrouterns version. Om en användare tilldelas en läsarroll till Virtual WAN-resursen och prenumerationen visar Azure Portal för den användaren att hubbroutern måste uppgraderas till den senaste versionen, även om hubben redan har den senaste versionen.
Om du ändrar prenumerationsstatusen för det virtuella ekernätverket från inaktiverad till aktiverad och sedan uppgraderar den virtuella hubben måste du uppdatera anslutningen till det virtuella nätverket efter uppgraderingen av den virtuella hubben (du kan till exempel konfigurera den virtuella nätverksanslutningen så att den sprids till en dummy-etikett).
Om din hubb är ansluten till ett stort antal virtuella ekernätverk (60 eller mer) kanske du märker att 1 eller fler eker-VNet-peerings kommer att ange ett feltillstånd efter uppgraderingen. Om du vill återställa dessa VNet-peerings till ett lyckat tillstånd efter uppgraderingen kan du konfigurera de virtuella nätverksanslutningarna så att de sprids till en dummyetikett, eller så kan du ta bort och återskapa dessa respektive VNet-anslutningar.
Varför kräver den virtuella hubbroutern en offentlig IP-adress med öppna portar?
Dessa offentliga slutpunkter krävs för att Azures underliggande SDN och hanteringsplattform ska kunna kommunicera med den virtuella hubbroutern. Eftersom den virtuella hubbroutern anses vara en del av kundens privata nätverk kan Azures underliggande plattform inte direkt komma åt och hantera hubbrouter via sina privata slutpunkter på grund av efterlevnadskrav. Anslutningen till hubbrouterns offentliga slutpunkter autentiseras via certifikat och Azure utför rutinmässiga säkerhetsgranskningar av dessa offentliga slutpunkter. Därför utgör de inte någon säkerhetsexponering för din virtuella hubb.
Finns det en väggräns för OpenVPN-klienter som ansluter till en Azure P2S VPN-gateway?
Väggränsen för OpenVPN-klienter är 1 000.
Hur beräknas SLA för Virtual WAN?
Virtual WAN är en plattform för nätverk som en tjänst som har ett serviceavtal på 99,95 %. Virtual WAN kombinerar dock många olika komponenter som Azure Firewall, plats-till-plats-VPN, ExpressRoute, punkt-till-plats-VPN och Virtual WAN Hub/Integrerade virtuella nätverksinstallationer.
Serviceavtalet för varje komponent beräknas individuellt. Om ExpressRoute till exempel har 10 minuters stilleståndstid beräknas tillgängligheten för ExpressRoute som (Maximalt antal tillgängliga minuter – stilleståndstid)/Maximalt antal tillgängliga minuter * 100.
Kan du ändra det virtuella nätverkets adressutrymme i ett eker-VNet som är anslutet till hubben?
Ja, detta kan göras automatiskt utan att någon uppdatering eller återställning krävs för peering-anslutningen. Observera följande:
- Du behöver inte klicka på knappen "Synkronisera" under bladet Peering. När det virtuella nätverkets adressutrymme har ändrats synkroniseras VNet-peering automatiskt med den virtuella hubbens virtuella nätverk.
- Kontrollera att det uppdaterade adressutrymmet inte överlappar adressutrymmet för befintliga virtuella ekernätverk i ditt virtuella WAN.
Mer information om hur du ändrar adressutrymmet för det virtuella nätverket finns här.
Vilket är det maximala antalet virtuella ekernätverksadresser som stöds för hubbar som konfigurerats med routningssyfte?
Det maximala antalet adressutrymmen i alla virtuella nätverk som är direkt anslutna till en enda Virtuell WAN-hubb är 400. Den här gränsen tillämpas individuellt på varje Virtual WAN-hubb i en Virtual WAN-distribution. Virtuella nätverksadressutrymmen som är anslutna till fjärranslutna (andra Virtual WAN-hubbar i samma Virtual WAN)-hubbar räknas inte mot den här gränsen.
Den här gränsen kan justeras. Mer information om gränsen finns i avsnittet om gränsökning och exempelskript för att fastställa antalet adressutrymmen i virtuella nätverk som är anslutna till en Virtuell WAN-hubb.
Virtuellt WAN-kundstyrt gatewayunderhåll
Vilka tjänster ingår i omfånget underhållskonfiguration för nätverksgatewayer?
För Virtual WAN kan du konfigurera underhållsperioder för plats-till-plats-VPN-gatewayer och ExpressRoute-gatewayer.
Vilket underhåll stöds eller stöds inte av kundkontrollerat underhåll?
Azure-tjänster genomgår regelbundna underhållsuppdateringar för att förbättra funktioner, tillförlitlighet, prestanda och säkerhet. När du har konfigurerat en underhållsperiod för dina resurser utförs underhåll av gästoperativsystem och tjänster under det fönstret. De här uppdateringarna står för de flesta underhållsobjekt som orsakar problem för kunderna.
Underliggande uppdateringar av värdmaskinvara och datacenterinfrastruktur omfattas inte av kundkontrollerat underhåll. Om det finns ett säkerhetsproblem med hög allvarlighetsgrad som kan äventyra våra kunder kan Azure dessutom behöva åsidosätta kundens kontroll över underhållsfönstret och distribuera ändringen. Det här är sällsynta förekomster som endast skulle användas i extrema fall.
Kan jag få ett avancerat meddelande om underhållet?
För närvarande kan avancerade meddelanden inte aktiveras för underhåll av Network Gateway-resurser.
Kan jag konfigurera en underhållsperiod som är kortare än fem timmar?
För närvarande måste du konfigurera minst ett femtimmarsfönster i önskad tidszon.
Kan jag konfigurera ett underhållsschema som inte upprepas dagligen?
För närvarande måste du konfigurera ett dagligt underhållsperiod.
Måste underhållskonfigurationsresurser finnas i samma region som gatewayresursen?
Ja.
Behöver jag distribuera en minsta gatewayskalningsenhet för att vara berättigad till kundkontrollerat underhåll?
Nej.
Hur lång tid tar det innan underhållskonfigurationsprincipen börjar gälla när den har tilldelats till gatewayresursen?
Det kan ta upp till 24 timmar innan Nätverksgatewayer följer underhållsschemat när underhållsprincipen är associerad med gatewayresursen.
Hur ska jag planera underhållsperioder när jag använder VPN och ExpressRoute i ett samexistensscenario?
När du arbetar med VPN och ExpressRoute i ett samexistensscenario eller när du har resurser som fungerar som säkerhetskopior rekommenderar vi att du konfigurerar separata underhållsperioder. Den här metoden säkerställer att underhåll inte påverkar dina säkerhetskopieringsresurser samtidigt.
Jag har schemalagt ett underhållsperiod för ett framtida datum för en av mina resurser. Kommer underhållsaktiviteter att pausas på den här resursen tills dess?
Nej, underhållsaktiviteter pausas inte på resursen under perioden före det schemalagda underhållsfönstret. Under de dagar som inte omfattas av underhållsschemat fortsätter underhållet som vanligt på resursen.
Finns det gränser för hur många vägar jag kan annonsera?
Ja, det finns gränser. ExpressRoute stöder upp till 4 000 prefix för privat peering och 200 prefix för Microsoft-peering. Med ExpressRoute Premium kan du öka gränsen till 10 000 vägar för privat peering. Det maximala antalet vägar som annonseras från privat Azure-peering via en ExpressRoute-gateway över en ExpressRoute-krets är 1 000, vilket är detsamma för både Standard- och Premium ExpressRoute-kretsar. Mer information finns i Väggränser för ExpressRoute-kretsar för Azure-prenumerationsgränser och kvoter . Observera att IPv6-vägannonser för närvarande inte stöds med Virtual WAN.
Finns det begränsningar för IP-intervall som jag kan annonsera över BGP-sessionen?
Ja, det finns begränsningar. Privata prefix (RFC1918) accepteras inte för Microsofts BGP-peeringsession. Dock godkänns alla prefixstorlekar upp till ett /32-prefix för både Microsoft och privat peering.
Vad händer om BGP-väggränsen överskrids?
Om BGP-routningsgränsen överskrids kopplas BGP-sessioner från. Sessionerna återställs när prefixantalet har minskats under gränsen. Mer information finns i ExpressRoute-kretsarNas routningsgränser på sidan Gränser och kvoter för Azure-prenumerationer.
Kan jag övervaka antalet vägar som annonseras eller tas emot via en ExpressRoute-krets?
Ja, det kan du. Metodtips och konfiguration för måttbaserad aviseringsövervakning finns i Metodtips för Azure-övervakning.
Vad är rekommendationen för att minska antalet IP-prefix?
Vi rekommenderar att du aggregerar prefixen innan du annonserar dem via ExpressRoute eller VPN-gateway. Dessutom kan du använda Route-Maps för att sammanfatta vägar som annonseras från/till Virtual WAN.
Nästa steg
Mer information om Virtual WAN finns i Om Virtual WAN.