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 Producten die beschikbaar zijn per regio om de beschikbare regio's voor Virtual WAN weer te geven. Geef Virtual WAN op als productnaam.

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.

Is het mogelijk om de firewall te delen in een beveiligde hub met andere hubs?

Nee, elke Virtuele Azure-hub moet een eigen firewall hebben. De implementatie van aangepaste routes om de firewall van een andere beveiligde hub te laten wijzen, mislukt en wordt niet voltooid. Overweeg deze hubs te converteren naar beveiligde hubs met hun eigen firewalls.

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 Besturingssysteem van windows 10-client 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.

1. 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 servers
   

2. Als 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 verbindingen	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.

Voor gebruikers-VPN (punt-naar-site) wordt de geregistreerde Microsoft-app ondersteund in Entra Id-verificatie?

Ja, de door Microsoft geregistreerde app wordt ondersteund in Virtual WAN. U kunt uw gebruikers-VPN migreren van handmatig geregistreerde app naar een door Microsoft geregistreerde app voor een veiligere connectiviteit.

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.

Biedt ExpressRoute ondersteuning voor ECMP-routering (Equal-Cost Multi-Path) in Virtual WAN?

Wanneer meerdere ExpressRoute-circuits zijn verbonden met een Virtual WAN-hub, zorgt ECMP ervoor dat verkeer van virtuele spoke-netwerken naar on-premises via ExpressRoute kan worden gedistribueerd over alle ExpressRoute-circuits die dezelfde on-premises routes adverteren. ECMP is momenteel niet standaard ingeschakeld voor Virtual WAN-hubs.

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.

Blijven BGP-community's die worden gegenereerd door BGP-peers (in een gekoppeld virtueel netwerk) bewaard in Virtual WAN?

Ja, BGP-community's die door BGP-peers worden gegenereerd, blijven behouden in Virtual WAN. Community's blijven behouden in dezelfde hub en tussen interhubverbindingen. Dit geldt ook voor Virtual WAN-scenario's met behulp van beleidsregels voor routeringsintentie.

Welke ASN-nummers worden ondersteund voor extern gekoppelde on-premises netwerken waarop BGP wordt uitgevoerd?

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 vereist de virtuele hubrouter een openbaar IP-adres met geopende poorten?

Deze openbare eindpunten zijn vereist voor het onderliggende SDN- en beheerplatform van Azure om te communiceren met de router van de virtuele hub. Omdat de virtuele hubrouter wordt beschouwd als onderdeel van het privénetwerk van de klant, kan het onderliggende Platform van Azure de hubrouter niet rechtstreeks openen en beheren via de privé-eindpunten vanwege nalevingsvereisten. Connectiviteit met de openbare eindpunten van de hubrouter wordt geverifieerd via certificaten en Azure voert routinematige beveiligingscontroles van deze openbare eindpunten uit. Als gevolg hiervan vormen ze geen beveiligingsblootstelling van uw virtuele hub.

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. Houd rekening met het volgende:

• U hoeft niet op de knop Synchroniseren onder de blade Peering te klikken. Zodra de adresruimte van het VNet is gewijzigd, wordt de VNet-peering automatisch gesynchroniseerd met het VNet van de virtuele hub.
• Zorg ervoor dat de bijgewerkte adresruimte niet overlapt met de adresruimte voor bestaande spoke-VNets in uw Virtual WAN.

Hier vindt u meer informatie over het wijzigen van de VNet-adresruimte.

Wat is het maximum aantal spoke Virtual Network-adressen dat wordt ondersteund voor hubs die zijn geconfigureerd met routeringsintentie?

Het maximum aantal adresruimten in alle virtuele netwerken dat rechtstreeks is verbonden met één Virtual WAN-hub is 400. Deze limiet wordt afzonderlijk toegepast op elke Virtual WAN-hub in een Virtual WAN-implementatie. Adresruimten van virtuele netwerken die zijn verbonden met externe (andere Virtual WAN-hubs in dezelfde Virtual WAN)-hubs, worden niet meegeteld voor deze limiet.

Deze limiet is aanpasbaar. Voor meer informatie over de limiet raadpleegt u de procedure voor het aanvragen van een limietverhoging en voorbeeldscripts om het aantal adresruimten in virtuele netwerken te bepalen dat is verbonden met een Virtual WAN-hub. Zie de limieten voor adresruimte voor virtuele netwerken voor routeringsintenties voor virtuele netwerken.

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.

Zijn er limieten voor het aantal routes dat ik kan adverteren?

Ja, er zijn limieten. ExpressRoute ondersteunt maximaal 4000 voorvoegsels voor persoonlijke peering en 200 voorvoegsels voor Microsoft-peering. Met ExpressRoute Premium kunt u de limiet verhogen tot 10.000 routes voor privépeering. Het maximum aantal routes dat wordt geadverteerd vanuit persoonlijke Azure-peering via een ExpressRoute-gateway via een ExpressRoute-circuit is 1000, wat hetzelfde is voor zowel standard- als premium ExpressRoute-circuits. Voor meer informatie kunt u de Routelimieten voor ExpressRoute-circuits bekijken op de pagina limieten en quota van Azure-abonnementen. Houd er rekening mee dat IPv6-routeadvertenties momenteel niet worden ondersteund met Virtual WAN.

Zijn er beperkingen voor IP-bereiken die ik kan adverteren via de BGP-sessie?

Ja, er zijn beperkingen. Privévoorvoegsels (RFC1918) worden niet geaccepteerd voor de BGP-sessie van Microsoft-peering. Elke grootte van het voorvoegsel tot een /32-voorvoegsel wordt echter geaccepteerd op zowel microsoft als persoonlijke peering.

Wat gebeurt er als de BGP-routelimiet wordt overschreden?

Als de BGP-routelimiet wordt overschreden, worden BGP-sessies verbroken. De sessies worden hersteld zodra het aantal voorvoegsels lager is dan de limiet. Zie de routelimieten voor ExpressRoute-circuits op de pagina limieten en quota voor Azure-abonnementen voor meer informatie.

Kan ik het aantal routes bewaken dat wordt geadverteerd of ontvangen via een ExpressRoute-circuit?

Ja, dat kan. Raadpleeg de aanbevolen procedures en configuratie voor waarschuwingsbewaking op basis van metrische gegevens.

Wat is de aanbeveling om het aantal IP-voorvoegsels te verminderen?

U wordt aangeraden de voorvoegsels te aggregeren voordat u deze adverteert via ExpressRoute of VPN-gateway. Daarnaast kunt u Route-Maps gebruiken om routes samen te vatten die zijn geadverteerd van/naar Virtual WAN.

Volgende stappen

Zie Over Virtual WAN voor meer informatie over Virtual WAN.