Veelgestelde vragen over Virtual WAN
Is Azure Virtual WAN algemeen beschikbaar?
Ja, Azure Virtual WAN is algemeen beschikbaar. Virtual WAN bestaat echter uit verschillende functies en scenario's. Er zijn functies of scenario's in Virtual WAN waar Microsoft de preview-tag toepast. In dergelijke gevallen is de specifieke functie of het scenario zelf een preview-versie. Als u geen specifieke preview-functie gebruikt, is reguliere GA-ondersteuning van toepassing. Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure-previews voor meer informatie over de ondersteuning van preview-versies.
Welke locaties en regio's zijn beschikbaar?
Zie Beschikbare locaties en regio's voor meer informatie.
Moet de gebruiker over hub en spoke beschikken met SD-WAN/VPN-apparaten om Azure Virtual WAN te kunnen gebruiken?
Virtual WAN biedt veel functies die zijn ingebouwd in één deelvenster glas, zoals site-/site-naar-site-VPN-connectiviteit, gebruikers-/P2S-connectiviteit, ExpressRoute-connectiviteit, virtuele netwerkconnectiviteit, VPN ExpressRoute-interconnectiviteit, transitieve VNet-naar-VNet-connectiviteit, gecentraliseerde routering, Beveiliging van Azure Firewall en Firewall Manager, bewaking, ExpressRoute-versleuteling en vele andere mogelijkheden. U hoeft niet al deze use cases te hebben om Virtual WAN te gaan gebruiken. U kunt aan de slag met slechts één use-case.
De Virtual WAN-architectuur is een hub- en spoke-architectuur met schaal en prestaties die zijn ingebouwd in vertakkingen (VPN/SD-WAN-apparaten), gebruikers (Azure VPN-clients, openVPN- of IKEv2-clients), ExpressRoute-circuits, virtuele netwerken fungeren als spokes naar virtuele hub(s). Alle hubs zijn verbonden in full mesh in een standaard virtuele WAN, waardoor de gebruiker de Microsoft-backbone eenvoudig kan gebruiken voor any-to-any-connectiviteit (elke willekeurige spoke). Voor hub en spoke met SD-WAN-/VPN-apparaten kunnen gebruikers het handmatig instellen in de Azure Virtual WAN-portal of gebruikmaken van de Azure Virtual-partner WAN CPE (SD-WAN/VPN) om connectiviteit met Azure in te stellen.
Virtual WAN-partners bieden automatisering voor connectiviteit, dus de mogelijkheid om de apparaatgegevens te exporteren naar Azure, de Azure-configuratie te downloaden en verbinding te maken met de Azure Virtual WAN-hub. Voor punt-naar-site-/gebruikers-VPN-connectiviteit ondersteunen we de Azure VPN-client, OpenVPN of IKEv2-client.
Kunnen volledig gemeshede hubs in een virtuele WAN worden uitgeschakeld?
Virtual WAN heeft twee varianten: Basic en Standard. In Basic Virtual WAN worden hubs niet meshed. In een Standard Virtual WAN worden hubs gemeshed en automatisch verbonden wanneer de virtuele WAN voor het eerst wordt ingesteld. De gebruiker hoeft niets specifieks te doen. De gebruiker hoeft de functionaliteit ook niet uit te schakelen of in te schakelen om meshed hubs te verkrijgen. Virtual WAN biedt u veel routeringsopties voor het sturen van verkeer tussen een spoke (VNet, VPN of ExpressRoute). Het biedt het gemak van volledig gemeshede hubs en tevens de flexibiliteit om verkeer naar behoefte te leiden.
Hoe worden beschikbaarheidszones en tolerantie in Virtual WAN verwerkt?
Virtual WAN is een verzameling hubs en services die beschikbaar zijn in de hub. De gebruiker kan over net zoveel virtuele WAN beschikken als nodig is. In een Virtual WAN-hub zijn er meerdere services zoals VPN, ExpressRoute, enzovoort. Elk van deze services wordt automatisch geïmplementeerd in Beschikbaarheidszones (behalve Azure Firewall), als de regio ondersteuning biedt voor Beschikbaarheidszones. Als een regio na de eerste implementatie in de hub een beschikbaarheidszone wordt, kan de gebruiker de gateways opnieuw maken, waardoor de implementatie van een beschikbaarheidszone wordt geactiveerd. Alle gateways worden ingericht in een hub als actief-actief, wat impliceert dat er tolerantie is ingebouwd in een hub. Gebruikers kunnen verbinding maken met meerdere hubs als ze tolerantie voor verschillende regio's willen.
Momenteel kan Azure Firewall worden geïmplementeerd ter ondersteuning van Beschikbaarheidszones met behulp van azure Firewall Manager Portal, PowerShell of CLI. Er is momenteel geen manier om een bestaande firewall te configureren die in beschikbaarheidszones moet worden geïmplementeerd. U moet uw Azure Firewall verwijderen en opnieuw implementeren.
Hoewel het concept van Virtual WAN globaal is, is de daadwerkelijke Virtual WAN-resource gebaseerd op Resource Manager en regionaal gedistribueerd. Als de virtuele WAN-regio zelf een probleem zou hebben, blijven alle hubs in die virtuele WAN werken zoals dat wil, maar kan de gebruiker pas nieuwe hubs maken als de virtuele WAN-regio beschikbaar is.
Welke client biedt ondersteuning voor vpn-gebruikers van Azure Virtual WAN (punt-naar-site)?
Virtual WAN ondersteunt Azure VPN Client, OpenVPN Client of een IKEv2-client. Microsoft Entra-verificatie wordt ondersteund met Azure VPN Client.Minimaal Versie 17763.0 of hoger van het Windows 10-clientbesturingssystemen is vereist. OpenVPN-client(s) kunnen verificatie op basis van certificaten ondersteunen. Zodra verificatie op basis van certificaten is geselecteerd op de gateway, ziet u het.ovpn*-bestand dat u naar uw apparaat wilt downloaden. IKEv2 ondersteunt zowel certificaat- als RADIUS-authenticatie.
Waarom wordt de P2S-clientgroep gesplitst in twee routes voor gebruikers-VPN (punt-naar-site)?
Elke gateway heeft twee exemplaren. De splitsing vindt plaats zodat elk gateway-exemplaar onafhankelijk client-IP's kan toewijzen voor verbonden clients en verkeer van het virtuele netwerk wordt doorgestuurd naar het juiste gateway-exemplaar om hop tussen gateway-exemplaren te voorkomen.
Hoe kan ik DNS-servers voor P2S-clients toevoegen?
Er zijn twee opties om DNS-servers voor de P2S-clients toe te voegen. De eerste methode verdient de voorkeur omdat hiermee de aangepaste DNS-servers aan de gateway worden toegevoegd in plaats van de client.
Gebruik het volgende PowerShell-script om de aangepaste DNS-servers toe te voegen. Vervang de waarden voor uw omgeving.
// 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 serversAls u de Azure VPN-client voor Windows 10 gebruikt, kunt u het gedownloade XML-profielbestand wijzigen en de dnsservers><dnsserver<>/dnsserver></dnsservers-tags toevoegen voordat u het importeert>.<
<azvpnprofile> <clientconfig> <dnsservers> <dnsserver>x.x.x.x</dnsserver> <dnsserver>y.y.y.y</dnsserver> </dnsservers> </clientconfig> </azvpnprofile>
Voor VPN voor gebruikers (punt-naar-site): hoeveel clients worden ondersteund?
In de onderstaande tabel wordt het aantal gelijktijdige verbindingen beschreven en de geaggregeerde doorvoer van de punt-naar-site-VPN-gateway die wordt ondersteund op verschillende schaaleenheden.
| Schaaleenheid | Gateway-exemplaren | Ondersteunde gelijktijdige Verbinding maken ions | Geaggregeerde doorvoer |
|---|---|---|---|
| 1 | 2 | 500 | 0,5 Gbps |
| 2 | 2 | 500 | 1 Gbps |
| 3 | 2 | 500 | 1,5 Gbps |
| 4 | 2 | 1000 | 2 Gbps |
| 5 | 2 | 1000 | 2,5 Gbps |
| 6 | 2 | 1000 | 3 Gbps |
| 7 | 2 | 5000 | 3,5 Gbps |
| 8 | 2 | 5000 | 4 Gbps |
| 9 | 2 | 5000 | 4,5 Gbps |
| 10 | 2 | 5000 | 5 Gbps |
| 11 | 2 | 10000 | 5,5 Gbps |
| 12 | 2 | 10000 | 6 Gbps |
| 13 | 2 | 10000 | 6,5 Gbps |
| 14 | 2 | 10000 | 7 Gbps |
| 15 | 2 | 10000 | 7,5 Gbps |
| 16 | 2 | 10000 | 8 Gbps |
| 17 | 2 | 10000 | 8,5 Gbps |
| 18 | 2 | 10000 | 9 Gbps |
| 19 | 2 | 10000 | 9,5 Gbps |
| 20 | 2 | 10000 | 10 Gbps |
| 40 | 4 | 20000 | 20 Gbps |
| 60 | 6 | 30.000 | 30 Gbps |
| 80 | 8 | 40.000 | 40 Gbps |
| 100 | 10 | 50000 | 50 Gbps |
| 120 | 12 | 60000 | 60 Gbps |
| 140 | 14 | 70000 | 70 Gbps |
| 160 | 16 | 80.000 | 80 Gbps |
| 180 | 18 | 90.000 | 90 Gbps |
| 200 | 20 | 100000 | 100 Gbps |
Stel dat de gebruiker 1 schaaleenheid kiest. Elke schaaleenheid impliceert een geïmplementeerde actief-actief-gateway en elk exemplaar (in dit geval twee) zou maximaal 500 verbindingen ondersteunen. Omdat u 500 verbindingen * 2 per gateway kunt krijgen, betekent dit niet dat u 1000 plant in plaats van de 500 voor deze schaaleenheid. Exemplaren moeten mogelijk worden onderhouden waarbij de connectiviteit voor de extra 500 mogelijk wordt onderbroken als u het aanbevolen aantal verbindingen overschrijdt.
Voor gateways met schaaleenheden groter dan 20 worden extra maximaal beschikbare paren van gateway-exemplaren geïmplementeerd om extra capaciteit te bieden voor het verbinden van gebruikers. Elk paar exemplaren ondersteunt maximaal 10.000 extra gebruikers. Als u bijvoorbeeld een gateway met 100 schaaleenheden implementeert, worden 5 gatewayparen (10 totaal aantal exemplaren) geïmplementeerd en kunnen gelijktijdige gebruikers verbinding maken met maximaal 50.000 (10.000 gebruikers x 5 gatewayparen).
Houd ook rekening met uitvaltijd voor het geval dat u de schaaleenheid omhoog of omlaag wilt schalen of de punt-naar-site-configuratie op de VPN-gateway wilt wijzigen.
Wat zijn schaaleenheden van een Virtual WAN-gateway?
Een schaaleenheid is een eenheid die is gedefinieerd om een geaggregeerde doorvoer van een gateway in een virtuele hub te kunnen kiezen. 1 VPN-schaaleenheid = 500 Mbps. 1 ExpressRoute-schaaleenheid = 2 Gbps. Voorbeeld: 10 schaaleenheden van VPN impliceren 500 Mbps * 10 = 5 Gbps.
Wat is het verschil tussen een virtuele Azure-netwerkgateway (VPN Gateway) en een Azure Virtual WAN VPN-gateway?
Virtual WAN biedt grootschalige site-naar-site-connectiviteit en is ontworpen met het oog op doorvoer, schaalbaarheid en gebruiksgemak. Wanneer u een site verbindt met een Virtual WAN VPN-gateway, verschilt deze van een gewone virtuele netwerkgateway die gebruikmaakt van een gatewaytype 'site-naar-site VPN'. Wanneer u externe gebruikers wilt verbinden met Virtual WAN, gebruikt u een gatewaytype 'punt-naar-site-VPN'. De punt-naar-site- en site-naar-site-VPN-gateways zijn afzonderlijke entiteiten in de Virtual WAN-hub en moeten afzonderlijk worden geïmplementeerd. En wanneer u een ExpressRoute-circuit verbindt met een Virtual WAN-hub, wordt er ook een andere resource gebruikt voor de ExpressRoute-gateway dan de normale virtuele netwerk-gateway, die gebruikmaakt van het gatewaytype ExpressRoute.
Virtual WAN ondersteunt maximaal 20 Gbps geaggregeerde doorvoer voor VPN en ExpressRoute. Virtual WAN beschikt ook over automatisering voor connectiviteit met een ecosysteem van CPE-vertakkingsapparaatpartners. CPE-vertakkingsapparaten beschikken over ingebouwde automatisering waarmee automatisch wordt ingericht en verbinding met Azure Virtual WAN wordt gemaakt. Deze apparaten zijn beschikbaar binnen een groeiend ecosysteem van SD-WAN- en VPN-partners. Zie de lijst met voorkeurspartner.
Waarin verschilt Virtual WAN van een virtuele Azure-netwerkgateway?
Een VPN van een virtuele netwerkgateway is beperkt tot 100 tunnels. U moet Virtual WAN gebruiken voor grootschalige VPN-verbindingen. U kunt maximaal 1000 vertakkingsverbindingen per virtuele hub verbinden met aggregaties van 20 Gbps per hub. Een verbinding is een actief-actief-tunnel van het on-premises VPN-apparaat naar de virtuele hub. U kunt ook meerdere virtuele hubs per regio hebben, wat betekent dat u meer dan 1000 vertakkingen kunt verbinden met één Azure-regio door meerdere Virtual WAN-hubs in die Azure-regio te implementeren, elk met een eigen site-naar-site-VPN-gateway.
Wat is het aanbevolen algoritme en pakketten per seconde per site-naar-site-exemplaar in Virtual WAN-hub? Hoeveel tunnels wordt per exemplaar ondersteund? Wat wordt de maximale doorvoer ondersteund in één tunnel?
Virtual WAN ondersteunt 2 actieve site-naar-site VPN-gateway-exemplaren in een virtuele hub. Dit betekent dat er twee actief-actief-actieve VPN-gatewayexemplaren in een virtuele hub zijn. Tijdens onderhoudsbewerkingen wordt elke instantie één voor één bijgewerkt, waardoor een gebruiker een korte afname van de geaggregeerde doorvoer van een VPN-gateway kan ervaren.
Hoewel Virtual WAN VPN veel algoritmen ondersteunt, wordt onze aanbeveling GCMAES256 voor zowel IPSEC-versleuteling als integriteit voor optimale prestaties. AES256 en SHA256 worden beschouwd als minder presterend en daarom kunnen prestatieverminderingen, zoals latentie en pakketverlies, worden verwacht voor vergelijkbare algoritmetypen.
Pakketten per seconde of PPS zijn een factor van het totale aantal pakketten en de doorvoer die per instantie wordt ondersteund. Dit is het beste te begrijpen met een voorbeeld. Stel dat een site-naar-site-VPN-gateway-exemplaar van 1 schaaleenheid van 500 Mbps is geïmplementeerd in een virtuele WAN-hub. Ervan uitgaande dat een pakketgrootte van 1400, verwachte PPS voor dat VPN Gateway-exemplaar op een maximum = [(500 Mbps * 1024 * 1024) /8/1400] ~ 47000.
Virtual WAN heeft concepten van VPN-verbinding, koppelingsverbinding en tunnels. Eén VPN-verbinding bestaat uit koppelingsverbindingen. Virtual WAN ondersteunt maximaal 4 koppelingsverbindingen in een VPN-verbinding. Elke koppelingsverbinding bestaat uit twee IPsec-tunnels die worden beëindigd in twee exemplaren van een actief-actief VPN-gateway die is geïmplementeerd in een virtuele hub. Het totale aantal tunnels dat kan worden beëindigd in één actief exemplaar is 1000, wat ook impliceert dat de doorvoer voor één exemplaar beschikbaar is, geaggregeerd in alle tunnels die verbinding maken met dat exemplaar. Elke tunnel heeft ook bepaalde doorvoerwaarden. In het geval van meerdere tunnels die zijn verbonden met een gateway met een lagere waardeschaaleenheid, kunt u het beste de behoefte per tunnel evalueren en een VPN-gateway plannen die een statistische waarde is voor doorvoer in alle tunnels die in het VPN-exemplaar worden beëindigd.
Waarden voor verschillende schaaleenheden die worden ondersteund in Virtual WAN
| Schaaleenheid | Maximale doorvoer per tunnel (Mbps) | Max. PPS per tunnel | Maximale doorvoer per exemplaar (Mbps) | Maximum aantal PPS per exemplaar |
|---|---|---|---|---|
| 1 | 500 | 47K | 500 | 47K |
| 2 | 1000 | 94K | 1000 | 94K |
| 3 | 1500 | 140K | 1500 | 140K |
| 4 | 1500 | 140K | 2000 | 187K |
| 5 | 1500 | 140K | 2500 | 234K |
| 6 | 1500 | 140K | 3000 | 281K |
| 7 | 2300 | 215K | 3500 | 328K |
| 8 | 2300 | 215K | 4000 | 374K |
| 9 | 2300 | 215K | 4500 | 421K |
| 10 | 2300 | 215K | 5000 | 468K |
| 11 | 2300 | 215K | 5500 | 515K |
| 12 | 2300 | 215K | 6000 | 562K |
| 13 | 2300 | 215K | 6500 | 609K |
| 14 | 2300 | 215K | 7000 | 655K |
| 15 | 2300 | 215K | 7500 | 702K |
| 16 | 2300 | 215K | 8000 | 749K |
| 17 | 2300 | 215K | 8500 | 796K |
| 18 | 2300 | 215K | 9000 | 843K |
| 19 | 2300 | 215K | 9500 | 889K |
| 20 | 2300 | 215K | 10000 | 936K |
Notitie
Alle getallen zijn gebaseerd op GCM-algoritme.
Welke apparaatproviders (Virtual WAN-partners) worden ondersteund?
Veel partners bieden momenteel ondersteuning voor de volledig geautomatiseerde Virtual WAN-ervaring. Zie Virtual WAN-partners voor meer informatie.
Wat zijn de stappen voor automatisering voor Virtual WAN-partners?
Zie Automatisering voor Virtual WAN-partners voor meer informatie.
Moet ik een apparaat van een voorkeurspartner gebruiken?
Nee U kunt ieder VPN-apparaat gebruiken dat voldoet aan de Azure-vereisten voor IKEv2/IKEv1 IPSec-ondersteuning. Virtual WAN heeft ook CPE-partneroplossingen waarmee de connectiviteit met Azure Virtual WAN wordt geautomatiseerd, waardoor het eenvoudiger wordt om IPsec VPN-verbindingen op schaal in te stellen.
Hoe automatiseren Virtual WAN-partners connectiviteit met Azure Virtual WAN?
Softwarematige oplossingen voor netwerkconnectiviteit beheren hun vertakkingsapparaten doorgaans met behulp van een controller of een knooppunt voor apparaatinrichting. De controller kan Azure API’s gebruiken om de connectiviteit met Azure Virtual WAN te automatiseren. De automatisering omvat het uploaden van vertakkingsgegevens, het downloaden van de Azure-configuratie, het instellen van IPsec-tunnels in Azure Virtual Hubs en het automatisch instellen van connectiviteit vanaf het vertakkingsapparaat naar Azure Virtual WAN. Wanneer u honderden vertakkingen hebt, kunt u eenvoudig verbinding maken met behulp van Virtual WAN CPE-partners, omdat dankzij het onboarden het niet meer nodig is grootschalige IPsec-connectiviteit in te stellen, te configureren en te beheren. Raadpleeg Virtual WAN partner automation (Automatisering voor Virtual WAN-partners) voor meer informatie.
Wat gebeurt er als een apparaat dat ik gebruik niet in de lijst met Virtual WAN-partners staat? Kan ik het nog steeds gebruiken om verbinding te maken met Azure Virtual WAN-VPN?
Ja, als het apparaat IPsec IKEv1 of IKEv2 ondersteunt. Virtual WAN-partners automatiseren de connectiviteit vanaf het apparaat tot Azure VPN-eindpunten. Dit impliceert de automatisering van stappen als het uploaden van vertakkingsgegevens, IPsec en configuratie en connectiviteit. Omdat uw apparaat niet afkomstig is van een Virtual WAN-partnerecosysteem, moet u het zware werk doen om de Azure-configuratie handmatig te nemen en uw apparaat bij te werken om IPsec-connectiviteit in te stellen.
Hoe worden nieuwe partners die niet worden vermeld in uw lijst met lanceringspartners, ge onboardd?
Alle virtuele WAN-API's zijn OpenAPI. U kunt de documentatie Automatisering van Virtual WAN-partners raadplegen om de technische haalbaarheid vast te stellen. Een ideale partner is iemand die een apparaat heeft dat kan worden ingericht voor een IKEv1 of IKEv2 IPSec-verbinding. Zodra het bedrijf de automatiseringswerkzaamheden voor het CPE-apparaat heeft voltooid op basis van de hierboven beschreven automatiseringsrichtlijnen, kunt u contact opnemen met azurevirtualwan@microsoft.com om hier te worden vermeld: Connectiviteit via partners. Als u een klant bent die een bepaalde bedrijfsoplossing als Virtual WAN-partner wilt laten vermelden, neemt u contact op met het bedrijf door een e-mailbericht naar Virtual WAN te azurevirtualwan@microsoft.comverzenden.
Hoe biedt Virtual WAN ondersteuning voor SD-WAN-apparaten?
Virtual WAN-partners automatiseren IPsec-connectiviteit voor Azure VPN-eindpunten. Als de Virtual WAN-partner een SD-WAN-provider is, wordt er geïmpliceerd dat de SD-WAN-controller automatisering en IPsec-connectiviteit met Azure VPN-eindpunten beheert. Als het SD-WAN-apparaat een eigen eindpunt vereist in plaats van Azure VPN voor een eigen SD-WAN-functionaliteit, kunt u het SD-WAN-eindpunt implementeren in een virtueel Azure-netwerk en naast Azure Virtual WAN bestaan.
Virtual WAN ondersteunt BGP-peering en biedt ook de mogelijkheid om NVA's te implementeren in een virtuele WAN-hub.
Hoeveel VPN-apparaten kunnen verbinding maken met één hub?
Per virtuele hub worden maximaal 1000 verbindingen ondersteund. Elke verbinding bestaat uit vier koppelingen en elke koppelingsverbinding ondersteunt twee tunnels die zich in een actief-actief-configuratie bevinden. De tunnels eindigen in een VPN-gateway van de virtuele Azure-hub. Koppelingen vertegenwoordigen de fysieke ISP-koppeling op het vertakkings-/VPN-apparaat.
Wat is een vertakkingsverbinding met Azure Virtual WAN?
Een verbinding van een vertakking of VPN-apparaat in Azure Virtual WAN is een VPN-verbinding die virtueel de VPN-site en de Azure VPN-gateway in een virtuele hub verbindt.
Wat gebeurt er als het on-premises VPN-apparaat slechts één tunnel heeft naar een Azure Virtual WAN VPN-gateway?
Een Azure Virtual WAN-verbinding bestaat uit 2 tunnels. Een Virtual WAN VPN-gateway wordt geïmplementeerd in een virtuele hub in de actief-actieve modus. Dit betekent dat er afzonderlijke tunnels zijn van on-premises apparaten die worden beëindigd op afzonderlijke exemplaren. Dit is de aanbeveling voor alle gebruikers. Als de gebruiker er echter voor kiest om slechts één tunnel te hebben naar een van de exemplaren van de Virtual WAN VPN-gateway, als er om welke reden dan ook (onderhoud, patches enzovoort) de gateway-instantie offline wordt gehaald, wordt de tunnel verplaatst naar het secundaire actieve exemplaar en kan de gebruiker opnieuw verbinding maken. BGP-sessies worden niet verplaatst tussen exemplaren.
Wat gebeurt er tijdens het opnieuw instellen van een gateway in een Virtual WAN VPN-gateway?
De knop Gateway opnieuw instellen moet worden gebruikt als uw on-premises apparaten allemaal werken zoals verwacht, maar de site-naar-site-VPN-verbinding in Azure heeft de status Verbinding verbroken. Virtual WAN VPN-gateways worden altijd geïmplementeerd in een actief-actief-status voor hoge beschikbaarheid. Dit betekent dat er op elk moment altijd meer dan één exemplaar in een VPN-gateway is geïmplementeerd. Wanneer de knop Gateway opnieuw instellen wordt gebruikt, worden de exemplaren in de VPN-gateway op een opeenvolgende manier opnieuw opgestart, zodat uw verbindingen niet worden onderbroken. Er is een korte tussenruimte wanneer verbindingen van het ene exemplaar naar het andere worden verplaatst, maar deze kloof moet minder dan een minuut duren. Houd er ook rekening mee dat het opnieuw instellen van de gateways uw openbare IP-adressen niet wijzigt.
Dit scenario is alleen van toepassing op de S2S-verbindingen.
Kan het on-premises VPN-apparaat verbinding maken met meerdere hubs?
Ja. In het begin loopt de verkeersstroom van het on-premises apparaat naar de dichtstbijzijnde Microsoft-netwerkrand en vervolgens naar de virtuele hub.
Zijn er nieuwe Resource Manager-resources beschikbaar voor Virtual WAN?
Ja, Virtual WAN beschikt over nieuwe Resource Manager-resources. Zie het overzicht voor meer informatie.
Kan ik mijn favoriete virtuele netwerkapparaat (in een virtueel NVA-netwerk) implementeren en gebruiken met Azure Virtual WAN?
Ja, u kunt het virtuele netwerk van uw favoriete netwerkapparaat (NVA) verbinden met azure Virtual WAN.
Kan ik een virtueel netwerkapparaat binnen de virtuele hub maken?
Een NVA (Network Virtual Appliance) kan worden geïmplementeerd in een virtuele hub. Zie Over NVA's in een Virtual WAN-hub voor stappen.
Kan een spoke-VNet een virtuele netwerkgateway hebben?
Nee Het spoke-VNet kan geen virtuele netwerkgateway hebben als het is verbonden met de virtuele hub.
Kan een spoke-VNet een Azure Route Server hebben?
Nee Het spoke-VNet kan geen routeserver hebben als het is verbonden met de virtuele WAN-hub.
Is er ondersteuning voor BGP in VPN-connectiviteit?
Ja, BGP wordt ondersteund. Wanneer u een VPN-site maakt, kunt u er de BGP-parameters opgeven. Dit impliceert dat alle verbindingen die zijn gemaakt in Azure voor die site worden ingeschakeld voor BGP.
Is er informatie over licentieverlening of prijzen beschikbaar voor Virtual WAN?
Ja. Zie de prijzenpagina.
Is het mogelijk om een Azure Virtual WAN te maken met een Resource Manager-sjabloon?
Een eenvoudige configuratie van één virtuele WAN met één hub en één VPN-site kan met behulp van een quickstart-sjabloon worden gemaakt. Virtual WAN is voornamelijk een service op basis van REST of de portal.
Kunnen spoke-VNets die zijn verbonden met een virtuele hub met elkaar communiceren (V2V Transit)?
Ja. Standard Virtual WAN ondersteunt transitieve VNet-naar-VNet-connectiviteit via de Virtual WAN-hub waarmee de VNets zijn verbonden. In virtual WAN-terminologie verwijzen we naar deze paden als 'lokale Virtual WAN-VNet-transit' voor VNets die zijn verbonden met een Virtual WAN-hub binnen één regio en 'wereldwijde Virtual WAN-VNet-transit' voor VNets die zijn verbonden via meerdere Virtual WAN-hubs in twee of meer regio's.
In sommige scenario's kunnen spoke-VNets ook rechtstreeks met elkaar worden gekoppeld met behulp van peering van virtuele netwerken, naast lokale of globale Virtual WAN-VNet-doorvoer. In dit geval heeft VNet-peering voorrang op de transitieve verbinding via de Virtual WAN-hub.
Is een vertakking-naar-vertakking-verbinding toegestaan in Virtual WAN?
Ja, een vertakking-naar-vertakking-verbinding is beschikbaar in Virtual WAN. Vertakking is conceptueel van toepassing op VPN-sites, ExpressRoute-circuits of punt-naar-site-/gebruikers-VPN-gebruikers. Het inschakelen van vertakking naar vertakking is standaard ingeschakeld en kan zich in de WAN-configuratie-instellingen bevinden. Hierdoor kunnen VPN-vertakkingen/gebruikers verbinding maken met andere VPN-vertakkingen en connectiviteit tussen VPN- en ExpressRoute-gebruikers.
Loopt vertakking-naar-vertakking-verkeer via Azure Virtual WAN?
Ja. Vertakkings-naar-vertakkingsverkeer loopt via Azure Virtual WAN.
Is voor Virtual WAN vanaf elke site ExpressRoute nodig?
Nee Virtual WAN vereist geen ExpressRoute vanaf elke site. Uw sites zijn mogelijk verbonden met een providernetwerk met behulp van een ExpressRoute-circuit. Voor sites die zijn verbonden met ExpressRoute met een virtuele hub en IPsec VPN in dezelfde hub, biedt virtuele hub transitconnectiviteit tussen de VPN- en ExpressRoute-gebruiker.
Is er een netwerkdoorvoer- of verbindingslimiet bij gebruik van Azure Virtual WAN?
Netwerkdoorvoer vindt per service in een virtuele WAN-hub plaats. In elke hub is de geaggregeerde DOORVOER van VPN maximaal 20 Gbps, de cumulatieve ExpressRoute-doorvoer is maximaal 20 Gbps en de geaggregeerde doorvoer van vpn-gebruikers/punt-naar-site-VPN is maximaal 200 Gbps. De router in virtuele hub ondersteunt maximaal 50 Gbps voor VNet-naar-VNet-verkeersstromen en gaat uit van een totaal van 2000 VM-werkbelastingen voor alle VNets die zijn verbonden met één virtuele hub.
Als u vooraf capaciteit wilt beveiligen zonder te hoeven wachten totdat de virtuele hub wordt uitgeschaald wanneer er meer doorvoer nodig is, kunt u de minimale capaciteit instellen of indien nodig wijzigen. Zie Over instellingen voor virtuele hubs - hubcapaciteit. Zie kosten voor infrastructuureenheden routeren op de pagina prijzen van Azure Virtual WAN voor gevolgen voor kosten.
Wanneer VPN-sites verbinding maken met een hub, doen ze dit met verbindingen. Virtual WAN ondersteunt maximaal 1000 verbindingen of 2000 IPsec-tunnels per virtuele hub. Wanneer externe gebruikers verbinding maken met een virtuele hub, maken ze verbinding met de P2S VPN-gateway, die ondersteuning biedt voor maximaal 100.000 gebruikers, afhankelijk van de schaaleenheid (bandbreedte) die is gekozen voor de P2S VPN-gateway in de virtuele hub.
Kan ik NAT-T gebruiken op mijn VPN-verbindingen?
Ja, NAT-traversal (NAT-T) wordt ondersteund. De Virtual WAN VPN-gateway voert geen NAT-achtige functionaliteit uit op de binnenste pakketten naar/van de IPsec-tunnels. Zorg er in deze configuratie voor dat het on-premises apparaat de IPsec-tunnel initieert.
Hoe kan ik een schaaleenheid configureren voor een specifieke instelling, zoals 20 Gbps?
Ga naar de VPN-gateway in een hub in de portal en klik vervolgens op de schaaleenheid om deze te wijzigen in de juiste instelling.
Kan het on-premises apparaat in Virtual WAN meerde ISP's parallel gebruiken of is er altijd sprake van één VPN-tunnel?
On-premises apparaat-oplossingen kunnen verkeersbeleid toepassen om verkeer via meerdere tunnels naar de Azure Virtual WAN-hub (VPN-gateway in de virtuele hub) te sturen.
Wat is wereldwijde doorvoerarchitectuur?
Zie De architectuur van het wereldwijde doorvoernetwerk en Virtual WAN voor meer informatie.
Hoe wordt het verkeer naar de Azure-backbone geleid?
Het verkeer volgt het patroon: branch device -ISP-Microsoft network edge-Microsoft> DC (hub VNet)->Microsoft network edge-ISP-branch>> device>>
Wat is er met dit model op elke locatie nodig? Alleen een internetverbinding?
Ja. Een internetverbinding en een fysiek apparaat dat IPsec ondersteunt, bij voorkeur van onze geïntegreerde Virtual WAN-partners. Optioneel kunt u de configuratie en verbinding met Azure vanaf het apparaat van voorkeur handmatig beheren.
Hoe kan ik standaardroute (0.0.0.0/0) inschakelen voor een verbinding (VPN, ExpressRoute of virtueel netwerk)?
In een virtuele hub kan een inmiddels bekende standaardroute worden doorgegeven naar een virtuele netwerk-/site-naar-site-VPN-/ExpressRoute-verbinding als de vlag voor de verbinding de status Ingeschakeld heeft. Deze vlag wordt weergegeven als de gebruiker een verbinding met een virtueel netwerk, een VPN-verbinding of een ExpressRoute aanpast. Deze vlag wordt standaard uitgeschakeld wanneer een site of een ExpressRoute-circuit met een hub wordt verbonden. Deze functie wordt standaard ingeschakeld wanneer een virtuele netwerkverbinding wordt toegevoegd om een VNet te verbinden met een virtuele hub.
De standaardroute is niet afkomstig uit de Virtual WAN-hub; de standaardroute wordt doorgegeven als deze al door de Virtual WAN-hub is geleerd als gevolg van het implementeren van een firewall in de hub of als voor een andere verbonden site geforceerde tunneling is ingeschakeld. Een standaardroute wordt niet doorgegeven tussen hubs (inter-hub).
Is het mogelijk om meerdere virtuele WAN-hubs in dezelfde regio te maken?
Ja. Klanten kunnen nu meer dan één hub maken in dezelfde regio voor hetzelfde Azure Virtual WAN.
Hoe selecteert de virtuele hub in een virtueel WAN het beste pad voor een route van meerdere hubs?
Zie de pagina routeringsvoorkeur voor virtuele hubs voor meer informatie.
Staat de Virtual WAN-hub connectiviteit tussen ExpressRoute-circuits toe?
Overgang van ER-naar-ER vindt altijd via Global Reach plaats. Virtuele hubgateways worden geïmplementeerd in DC- of Azure-regio's. Wanneer twee ExpressRoute-circuits verbinding maken via Global Reach, hoeft het verkeer niet helemaal van de edge-routers naar de virtuele hub-DC te komen.
Speelt het concept gewicht een rol bij Azure Virtual WAN ExpressRoute-circuits or VPN-verbindingen
Wanneer meerdere ExpressRoute-circuits met een virtuele hub zijn verbonden, biedt de mate van routering (gewicht) voor de verbinding een mechanisme waarmee ExpressRoute in de virtuele hub een voorkeur heeft voor het ene circuit boven het andere. Er is geen mechanisme om een gewicht in te stellen voor een VPN-verbinding. Azure geeft binnen één hub altijd de voorkeur aan een ExpressRoute-verbinding boven een VPN-verbinding.
Is er een voorkeur van Virtual WAN voor ExpressRoute boven VPN voor verkeer dat Azure verlaat?
Ja. Virtual WAN geeft de voorkeur aan ExpressRoute via VPN voor uitgaand verkeer van Azure. U kunt de routeringsvoorkeur voor virtuele hubs echter configureren om de standaardvoorkeur te wijzigen. Zie Routeringsvoorkeur voor virtuele hubs configureren voor stappen.
Wanneer een Virtual WAN-hub een ExpressRoute-circuit en een VPN-site heeft verbonden, wat zou ervoor zorgen dat een VPN-verbindingsroute de voorkeur heeft boven ExpressRoute?
Wanneer een ExpressRoute-circuit is verbonden met een virtuele hub, zijn de Microsoft Edge-routers het eerste knooppunt voor communicatie tussen on-premises en Azure. Deze randrouters communiceren met de Virtual WAN ExpressRoute-gateways die op hun beurt routes bewaren van de virtuele hubrouter waarmee alle routes tussen gateways in Virtual WAN worden beheerd. De Microsoft Edge-routers verwerken ExpressRoute-routes van virtuele hubs met een hogere voorkeur dan routes die zijn geleerd van on-premises.
Als de VPN-verbinding om welke reden dan ook het primaire medium wordt voor de virtuele hub om routes te leren van (bijvoorbeeld failoverscenario's tussen ExpressRoute en VPN), tenzij de VPN-site een langere AS-padlengte heeft, blijft de virtuele hub geleerde ROUTES delen met de ExpressRoute-gateway. Hierdoor geven de Microsoft Edge-routers de voorkeur aan VPN-routes via on-premises routes.
Wanneer twee hubs (hub 1 en 2) zijn verbonden en er een ExpressRoute-circuit is verbonden als een bow-tie met beide hubs, wat is het pad voor een VNet dat is verbonden met hub 1 om een VNet te bereiken dat is verbonden in hub 2?
Het huidige gedrag is om de voorkeur te geven aan het ExpressRoute-circuit boven hub-naar-hub voor VNet-naar-VNet-connectiviteit. Dit wordt echter niet aangemoedigd in een Virtual WAN-installatie. U kunt dit oplossen door een van de volgende twee dingen uit te voeren:
Configureer meerdere ExpressRoute-circuits (verschillende providers) om verbinding te maken met één hub en gebruik te maken van de hub-naar-hub-connectiviteit die wordt geleverd door Virtual WAN voor verkeersstromen tussen regio's.
Configureer AS-pad als de hubrouteringsvoorkeur voor uw virtuele hub. Dit zorgt ervoor dat verkeer tussen de 2 hubs via de virtuele hubrouter in elke hub wordt geleid en het hub-naar-hub-pad gebruikt in plaats van het ExpressRoute-pad (dat door de Microsoft Edge-routers loopt). Raadpleeg Routeringsvoorkeur voor virtuele hubs configureren voor meer informatie.
Wanneer er een ExpressRoute-circuit is verbonden als een bow-tie met een Virtual WAN-hub en een zelfstandig VNet, wat is het pad voor het zelfstandige VNet om de Virtual WAN-hub te bereiken?
Voor nieuwe implementaties wordt deze connectiviteit standaard geblokkeerd. Als u deze connectiviteit wilt toestaan, kunt u deze ExpressRoute-gateway-wisselknoppen inschakelen op de blade Virtuele hub bewerken en de gateway van het virtuele netwerk in de portal. Het wordt echter aanbevolen deze wisselknoppen uitgeschakeld te houden en in plaats daarvan een virtuele netwerkverbinding te maken om zelfstandige VNets rechtstreeks te verbinden met een Virtual WAN-hub. Daarna loopt het VNet-naar-VNet-verkeer via de Virtual WAN-hubrouter, die betere prestaties biedt dan het ExpressRoute-pad. Het ExpressRoute-pad bevat de ExpressRoute-gateway, die lagere bandbreedtelimieten heeft dan de hubrouter, evenals de Microsoft Enterprise Edge-routers/MSEE. Dit is een extra hop in het gegevenspad.
In het onderstaande diagram moeten beide wisselknoppen zijn ingeschakeld om connectiviteit mogelijk te maken tussen het zelfstandige VNet 4 en de VNets die rechtstreeks zijn verbonden met hub 2 (VNet 2 en VNet 3): Verkeer van externe Virtual WAN-netwerken voor de gateway van het virtuele netwerk toestaan en verkeer van niet-Virtual WAN-netwerken toestaan voor de ExpressRoute-gateway van de virtuele hub. Als een Azure Route Server is geïmplementeerd in een zelfstandig VNet 4 en de routeserver vertakking naar vertakking is ingeschakeld, wordt de verbinding tussen VNet 1 en zelfstandige VNet 4 geblokkeerd.
Als u de wisselknop inschakelt of uitschakelt, heeft dit alleen invloed op de volgende verkeersstroom: verkeer tussen de Virtual WAN-hub en zelfstandige VNet(s) via het ExpressRoute-circuit. Als u de wisselknop inschakelt of uitschakelt, treedt er geen downtime op voor alle andere verkeersstromen (bijvoorbeeld: on-premises site naar spoke VNet 2 wordt niet beïnvloed, VNet 2 naar VNet 3 wordt niet beïnvloed, enzovoort).
Kunnen hubs worden gemaakt in verschillende resourcegroepen in Virtual WAN?
Ja. Deze optie is momenteel alleen beschikbaar via PowerShell. Voor de Virtual WAN-portal moeten de hubs zich in dezelfde resourcegroep bevinden als de Virtual WAN-resource zelf.
Wat is de aanbevolen hubadresruimte tijdens het maken van de hub?
De aanbevolen adresruimte van de Virtual WAN-hub is /23. Virtual WAN-hub wijst subnetten toe aan verschillende gateways (ExpressRoute, site-naar-site-VPN, punt-naar-site-VPN, Azure Firewall, Virtuele-hubrouter). Voor scenario's waarin NVA's worden geïmplementeerd in een virtuele hub, wordt een /28 doorgaans uitgesneden voor de NVA-exemplaren. Als de gebruiker echter meerdere NVA's inricht, kan er een /27-subnet worden toegewezen. Houd daarom rekening met een toekomstige architectuur, terwijl Virtual WAN-hubs worden geïmplementeerd met een minimale grootte van /24, de aanbevolen hubadresruimte tijdens het maken van de invoer van de gebruiker is /23.
Is er ondersteuning voor IPv6 in Virtual WAN?
IPv6 wordt niet ondersteund in de Virtual WAN-hub en de gateways. Dit scenario wordt momenteel niet ondersteund als u een VNet hebt met IPv4- en IPv6-ondersteuning en u het VNet wilt verbinden met Virtual WAN.
Voor het punt-naar-site-gebruikers-VPN-scenario met internetonderbreking via Azure Firewall moet u waarschijnlijk IPv6-connectiviteit op uw clientapparaat uitschakelen om verkeer naar de Virtual WAN-hub af te dwingen. Dit komt doordat moderne apparaten standaard IPv6-adressen gebruiken.
Wat is de aanbevolen API-versie die door scripts moet worden gebruikt om verschillende Virtual WAN-functionaliteit te automatiseren?
Een minimale versie van 05-01-2022 (1 mei 2022) is vereist.
Zijn er limieten voor Virtual WAN van toepassing?
Raadpleeg het gedeelte Limieten voor Virtual WAN op de pagina Abonnements- en servicebeperkingen.
Wat zijn de verschillen tussen de Virtual WAN-typen (Basic en Standard)?
Zie Virtual WAN's: Basic en Standard. Zie de pagina Prijzen voor prijsopgaven.
Slaat Virtual WAN klantgegevens op?
Nee Virtual WAN slaat geen klantgegevens op.
Zijn er Managed Service Providers die Virtual WAN voor gebruikers kunnen beheren als een service?
Ja. Raadpleeg Azure Marketplace-aanbiedingen van Azure-netwerken MSP-partners voor een lijst met MSP-oplossingen (Managed Service Provider) die beschikbaar zijn via Azure Marketplace.
Hoe verschilt routering van Virtual WAN-hubs van Azure Route Server in een VNet?
Zowel Azure Virtual WAN-hub als Azure Route Server bieden BGP-peeringmogelijkheden (Border Gateway Protocol) die kunnen worden gebruikt door NVA's (Virtueel netwerkapparaat) om IP-adressen van de NVA te adverteren naar de virtuele Azure-netwerken van de gebruiker. De implementatieopties verschillen in de zin dat Azure Route Server doorgaans wordt geïmplementeerd door een zelfbeheerd VNet van de klanthub, terwijl Azure Virtual WAN een volledig meshed hub-service biedt waarmee klanten hun verschillende spokes-eindpunten verbinden (Azure VNet, on-premises vertakkingen met site-naar-site VPN of SDWAN, externe gebruikers met punt-naar-site/externe gebruikers-VPN en privéverbindingen met ExpressRoute) en bGP-peering voor NVA's die zijn geïmplementeerd in spoke-VNet, samen met andere vWAN's mogelijkheden zoals transitconnectiviteit voor VNet-naar-VNet, transitconnectiviteit tussen VPN en ExpressRoute, aangepaste/geavanceerde routering, aangepaste routekoppeling en doorgifte, routeringsintentie/beleid voor geen gedoe tussen regio's, Secure Hub/Azure-firewall, enzovoort. Zie BGP-peering van Virtual WAN koppelen aan een virtuele hub voor meer informatie over Virtual WAN BGP-peering.
Als ik een externe beveiligingsprovider (Zscaler, iBoss of Checkpoint) gebruik om mijn internetverkeer te beveiligen, zie ik de VPN-site die is gekoppeld aan de externe beveiligingsprovider niet in de Azure-portal?
Wanneer u ervoor kiest om een beveiligingspartnerprovider te implementeren om internettoegang voor uw gebruikers te beveiligen, maakt de externe beveiligingsprovider namens u een VPN-site. Omdat de externe beveiligingsprovider automatisch wordt gemaakt door de provider en geen door de gebruiker gemaakte VPN-site is, wordt deze VPN-site niet weergegeven in Azure Portal.
Zie Een beveiligingspartnerprovider implementeren voor meer informatie over de beschikbare opties van externe beveiligingsproviders en het instellen hiervan.
Blijven BGP-community's die door on-premises worden gegenereerd, behouden in Virtual WAN?
Ja, BGP-community's die door on-premises worden gegenereerd, blijven behouden in Virtual WAN. U kunt uw eigen openbare ASN's of privé-ASN's gebruiken voor uw on-premises netwerken. U kunt de bereiken die zijn gereserveerd door Azure of IANA niet gebruiken:
- ASN's die zijn gereserveerd door Azure:
- Openbare ASN's: 8074, 8075, 12076
- Privé-ASN's: 65515, 65517, 65518, 65519, 65520
- ASN's gereserveerd door IANA: 23456, 64496-64511, 65535-65551
Is er een manier om de ASN voor een VPN-gateway te wijzigen?
Nee Virtual WAN biedt geen ondersteuning voor ASN-wijzigingen voor VPN-gateways.
Wat zijn in Virtual WAN de geschatte prestaties van de ExpressRoute-gateway-SKU?
| Schaaleenheid | Verbindingen per seconde | Mega-bits per seconde | Pakketten per seconde |
|---|---|---|---|
| 1 schaaleenheid |
14.000 | 2.000 | 200.000 |
| 2 schaaleenheden |
28.000 | 4000 | 400,000 |
| 3 schaaleenheden |
42,000 | 6.000 | 600,000 |
| 4 schaaleenheden |
56,000 | 8,000 | 800,000 |
| 5 schaaleenheden |
70,000 | 10.000 | 1.000.000 |
| 6 schaaleenheden |
84,000 | 12,000 | 1,200,000 |
| 7 schaaleenheden |
98,000 | 14.000 | 1,400,000 |
| 8 schaaleenheden |
112,000 | 16.000 | 1,600,000 |
| 9 schaaleenheden |
126,000 | 18.000 | 1,800,000 |
| 10 schaaleenheden |
140,000 | 20,000 | 2,000,000 |
Schaaleenheden 2-10, tijdens onderhoudsbewerkingen, onderhouden geaggregeerde doorvoer. Schaaleenheid 1 kan tijdens een onderhoudsbewerking echter een kleine variatie in doorvoernummers zien.
Als ik een Lokaal ExpressRoute-circuit verbindt met een Virtual WAN-hub, heb ik alleen toegang tot regio's op dezelfde metrolocatie als het lokale circuit?
Lokale circuits kunnen alleen worden verbonden met ExpressRoute-gateways in hun bijbehorende Azure-regio. Er is echter geen beperking voor het routeren van verkeer naar virtuele spoke-netwerken in andere regio's.
Waarom zie ik een bericht en knop met de naam 'Router bijwerken naar de nieuwste softwareversie' in de portal?
Notitie
Vanaf januari 2024 is het Virtual WAN-team begonnen met het upgraden van virtuele hubs naar de nieuwste versie. Als u uw hub niet hebt bijgewerkt, maar u ziet nu dat de routerversie van uw hub 'nieuwste' zegt, is uw hub bijgewerkt door het Virtual WAN-team.
De infrastructuur op basis van Cloud Services in Azure wordt afgeschaft. Als gevolg hiervan heeft het Virtual WAN-team gewerkt aan het upgraden van virtuele routers van hun huidige Cloud Services-infrastructuur naar implementaties op basis van virtuele-machineschaalsets. Alle nieuw gemaakte virtuele hubs worden automatisch geïmplementeerd op de nieuwste infrastructuur op basis van virtuele-machineschaalsets. Als u naar uw Virtual WAN-hubresource navigeert en dit bericht en deze knop ziet, kunt u uw router upgraden naar de nieuwste versie door op de knop te klikken. Als u wilt profiteren van nieuwe Virtual WAN-functies, zoals BGP-peering met de hub, moet u uw virtuele hubrouter bijwerken via Azure Portal. Als de knop niet zichtbaar is, opent u een ondersteuningsaanvraag.
U kunt uw virtuele hubrouter alleen bijwerken als alle resources (gateways/routetabellen/VNet-verbindingen) in uw hub de status Geslaagd hebben. Zorg ervoor dat al uw virtuele spoke-netwerken actief/ingeschakeld zijn en dat uw virtuele spoke-netwerken niet worden verwijderd. Aangezien voor deze bewerking de implementatie van nieuwe virtuele-machineschaalsets op basis van virtuele hubrouters is vereist, krijgt u een verwachte downtime van 1-2 minuten voor VNet-naar-VNet-verkeer via dezelfde hub en 5-7 minuten voor alle andere verkeerstromen via de hub. Binnen één Virtual WAN-resource moeten hubs één voor één worden bijgewerkt in plaats van meerdere tegelijk bij te werken. Wanneer de routerversie 'Nieuwste' zegt, wordt de hub bijgewerkt. Er zijn geen wijzigingen in het routeringsgedrag na deze update.
Er zijn verschillende dingen om rekening mee te houden met de upgrade van de router van de virtuele hub:
Als u BGP-peering al hebt geconfigureerd tussen uw Virtual WAN-hub en een NVA in een spoke-VNet, moet u de BGP-peer verwijderen en vervolgens opnieuw maken. Omdat de IP-adressen van de virtuele hubrouter na de upgrade veranderen, moet u uw NVA ook opnieuw configureren om te koppelen aan de nieuwe IP-adressen van de virtuele hubrouter. Deze IP-adressen worden weergegeven als het veld virtualRouterIps in de resource-JSON van de virtuele hub.
Als u een virtueel netwerkapparaat (NVA) in de virtuele hub hebt, moet u samenwerken met uw NVA-partner om instructies te verkrijgen voor het upgraden van uw Virtual WAN-hub.
Als uw virtuele hub is geconfigureerd met meer dan 15 routeringsinfrastructuureenheden, schaalt u in uw virtuele hub naar 2 eenheden voor routeringsinfrastructuur voordat u een upgrade uitvoert. U kunt uw hub terugschalen naar meer dan 15 routeringsinfrastructuur-eenheden na het upgraden van uw hub.
Als de update om welke reden dan ook mislukt, wordt uw hub automatisch hersteld naar de oude versie om ervoor te zorgen dat er nog steeds een werkende installatie is.
Aanvullende zaken die u moet noteren:
De gebruiker moet de rol eigenaar of inzender hebben om een nauwkeurige status van de hubrouterversie te kunnen zien. Als aan een gebruiker een lezerrol is toegewezen aan de Virtual WAN-resource en het abonnement, geeft Azure Portal aan die gebruiker weer dat de hubrouter moet worden bijgewerkt naar de nieuwste versie, zelfs als de hub al de nieuwste versie heeft.
Als u de abonnementsstatus van het spoke-virtuele netwerk wijzigt van uitgeschakeld naar ingeschakeld en vervolgens de virtuele hub bijwerkt, moet u de virtuele netwerkverbinding bijwerken na de upgrade van de virtuele hub (bijvoorbeeld: u kunt de virtuele netwerkverbinding zo configureren dat deze wordt doorgegeven aan een dummy-label).
Als uw hub is verbonden met een groot aantal virtuele spoke-netwerken (60 of meer), ziet u mogelijk dat 1 of meer spoke-VNet-peerings na de upgrade de status Mislukt hebben. Als u deze VNet-peerings na de upgrade wilt herstellen naar een geslaagde status, kunt u de verbindingen van het virtuele netwerk zo configureren dat ze worden doorgegeven aan een dummy-label, of u kunt deze respectieve VNet-verbindingen verwijderen en opnieuw maken.
Is er een routelimiet voor OpenVPN-clients die verbinding maken met een Azure P2S VPN-gateway?
De routelimiet voor OpenVPN-clients is 1000.
Hoe wordt de SLA van Virtual WAN berekend?
Virtual WAN is een platform voor netwerken als een service met een SLA van 99,95%. Virtual WAN combineert echter veel verschillende onderdelen, zoals Azure Firewall, site-naar-site-VPN, ExpressRoute, punt-naar-site-VPN en Virtual WAN Hub/Integrated Network Virtual Appliances.
De SLA voor elk onderdeel wordt afzonderlijk berekend. Als ExpressRoute bijvoorbeeld uitvaltijd van 10 minuten heeft, wordt de beschikbaarheid van ExpressRoute berekend als (maximaal beschikbare minuten - downtime) / Maximum beschikbare minuten * 100.
Kunt u de VNet-adresruimte wijzigen in een spoke-VNet dat is verbonden met de hub?
Ja, dit kan automatisch worden gedaan zonder update of opnieuw instellen vereist voor de peeringverbinding. Hier vindt u meer informatie over het wijzigen van de VNet-adresruimte.
Onderhoud van virtuele WAN door de klant beheerde gateway
Welke services zijn opgenomen in het bereik Onderhoudsconfiguratie van netwerkgateways?
Voor Virtual WAN kunt u onderhoudsvensters configureren voor site-naar-site-VPN-gateways en ExpressRoute-gateways.
Welk onderhoud wordt ondersteund of niet ondersteund door door de klant beheerd onderhoud?
Azure-services doorlopen periodieke onderhoudsupdates om de functionaliteit, betrouwbaarheid, prestaties en beveiliging te verbeteren. Zodra u een onderhoudsvenster voor uw resources hebt geconfigureerd, worden onderhoud van gastbesturingssystemen en services uitgevoerd tijdens dat venster. Deze updates zijn verantwoordelijk voor de meeste onderhoudsitems die zorgen voor klanten veroorzaken.
Updates voor onderliggende hosthardware- en datacenterinfrastructuur vallen niet onder onderhoud dat door de klant wordt beheerd. Als er bovendien een beveiligingsprobleem met hoge ernst is dat onze klanten in gevaar kan brengen, moet Azure mogelijk het beheer van de klant overschrijven van het onderhoudsvenster en de wijziging uitrollen. Dit zijn zeldzame gevallen die alleen in extreme gevallen zouden worden gebruikt.
Kan ik geavanceerde meldingen krijgen over het onderhoud?
Op dit moment kan geavanceerde melding niet worden ingeschakeld voor het onderhoud van netwerkgatewayresources.
Kan ik een onderhoudsvenster korter dan vijf uur configureren?
Op dit moment moet u minimaal een periode van vijf uur configureren in de tijdzone van uw voorkeur.
Kan ik een onderhoudsschema configureren dat niet dagelijks wordt herhaald?
Op dit moment moet u een dagelijks onderhoudsvenster configureren.
Moeten onderhoudsconfiguratieresources zich in dezelfde regio bevinden als de gatewayresource?
Ja.
Moet ik een minimale gatewayschaaleenheid implementeren om in aanmerking te komen voor door de klant beheerd onderhoud?
Nee
Hoe lang duurt het voordat het configuratiebeleid voor onderhoud van kracht wordt nadat het is toegewezen aan de gatewayresource?
Het kan tot 24 uur duren voordat netwerkgateways het onderhoudsschema volgen nadat het onderhoudsbeleid is gekoppeld aan de gatewayresource.
Hoe moet ik onderhoudsvensters plannen bij het gebruik van VPN en ExpressRoute in een co-existentiescenario?
Bij het werken met VPN en ExpressRoute in een co-existentiescenario of wanneer u resources hebt die fungeren als back-ups, raden we u aan afzonderlijke onderhoudsvensters in te stellen. Deze aanpak zorgt ervoor dat onderhoud niet tegelijkertijd van invloed is op uw back-upbronnen.
Ik heb een onderhoudsvenster gepland voor een toekomstige datum voor een van mijn resources. Worden onderhoudsactiviteiten tot die tijd onderbroken voor deze resource?
Nee, onderhoudsactiviteiten worden tijdens de periode vóór het geplande onderhoudsvenster niet onderbroken op uw resource. Voor de dagen die niet in uw onderhoudsplanning vallen, wordt het onderhoud op de gebruikelijke manier voortgezet op de resource.