FAQ da WAN Virtual

A WAN Virtual do Azure está no GA?

Sim, a WAN Virtual do Azure está disponível em geral (GA). No entanto, a WAN Virtual consiste em vários recursos e cenários. Há recursos ou cenários na WAN Virtual em que a Microsoft aplica a marca de visualização. Nesses casos, o recurso específico, ou o cenário em si, está em Visualização. Se você não usar um recurso de visualização específico, o suporte regular do GA será aplicado. Para obter mais informações sobre o suporte à Pré-visualização, consulte Termos de Utilização Suplementares para Pré-visualizações do Microsoft Azure.

Que locais e regiões estão disponíveis?

Para visualizar as regiões disponíveis para WAN Virtual, consulte Produtos disponíveis por região. Especifique a WAN Virtual como o nome do produto.

O usuário precisa ter hub e falou com dispositivos SD-WAN/VPN para usar a WAN Virtual do Azure?

A WAN Virtual fornece muitas funcionalidades incorporadas em um único painel, como conectividade VPN site/site a site, conectividade User/P2S, conectividade ExpressRoute, conectividade de rede virtual, interconectividade VPN ExpressRoute, conectividade transitiva VNet-to-VNet, Roteamento centralizado, segurança do Firewall do Azure e do Firewall Manager, monitoramento, criptografia de Rota Expressa e muitos outros recursos. Você não precisa ter todos esses casos de uso para começar a usar a WAN Virtual. Você pode começar com apenas um caso de uso.

A arquitetura WAN Virtual é uma arquitetura de hub e spoke com escala e desempenho integrados onde filiais (dispositivos VPN/SD-WAN), usuários (Clientes VPN do Azure, openVPN ou Clientes IKEv2), circuitos de Rota Expressa, redes virtuais servem como porta-vozes para hubs virtuais. Todos os hubs são conectados em malha completa em uma WAN Virtual Padrão, tornando mais fácil para o usuário usar o backbone da Microsoft para qualquer conectividade (qualquer falada). Para hub e spoke com dispositivos SD-WAN/VPN, os usuários podem configurá-lo manualmente no portal da WAN Virtual do Azure ou usar o Virtual WAN Partner CPE (SD-WAN/VPN) para configurar a conectividade com o Azure.

Os parceiros de WAN virtual fornecem automação para conectividade, que é a capacidade de exportar as informações do dispositivo para o Azure, baixar a configuração do Azure e estabelecer conectividade com o hub WAN Virtual do Azure. Para conectividade VPN ponto-a-site/utilizador, suportamos o cliente VPN do Azure, OpenVPN ou cliente IKEv2.

Você pode desativar hubs totalmente entrelaçados em uma WAN Virtual?

A WAN Virtual vem em dois sabores: Basic e Standard. Na WAN Virtual Básica, os hubs não são entrelaçados. Em uma WAN virtual padrão, os hubs são interligados e conectados automaticamente quando a WAN virtual é configurada pela primeira vez. O usuário não precisa fazer nada específico. O usuário também não precisa desativar ou habilitar a funcionalidade para obter hubs de malha. A WAN virtual fornece muitas opções de roteamento para direcionar o tráfego entre qualquer spoke (VNet, VPN ou ExpressRoute). Ele fornece a facilidade de hubs totalmente interligados e também a flexibilidade de roteamento de tráfego de acordo com suas necessidades.

Como as zonas de disponibilidade e a resiliência são tratadas na WAN virtual?

A WAN virtual é uma coleção de hubs e serviços disponibilizados dentro do hub. O usuário pode ter quantas WAN virtuais por sua necessidade. Em um hub WAN virtual, há vários serviços como VPN, ExpressRoute, etc. Cada um desses serviços é implantado automaticamente nas Zonas de Disponibilidade (exceto o Firewall do Azure), se a região oferecer suporte a Zonas de Disponibilidade. Se uma região se tornar uma Zona de Disponibilidade após a implantação inicial no hub, o usuário poderá recriar os gateways, o que acionará uma implantação da Zona de Disponibilidade. Todos os gateways são provisionados em um hub como ativo-ativo, o que implica que há resiliência interna em um hub. Os usuários podem se conectar a vários hubs se quiserem resiliência entre regiões.

Atualmente, o Firewall do Azure pode ser implantado para dar suporte a Zonas de Disponibilidade usando o Portal do Gerenciador de Firewall do Azure, PowerShell ou CLI. Atualmente, não é possível configurar um Firewall existente para ser implantado em zonas de disponibilidade. Você precisará excluir e reimplantar seu Firewall do Azure.

Embora o conceito de WAN Virtual seja global, o recurso de WAN Virtual real é baseado no Gerenciador de Recursos e implantado regionalmente. Se a própria região WAN virtual tiver um problema, todos os hubs nessa WAN virtual continuarão a funcionar como estão, mas o usuário não poderá criar novos hubs até que a região WAN virtual esteja disponível.

É possível compartilhar o Firewall em um hub protegido com outros hubs?

Não, cada Hub Virtual do Azure deve ter seu próprio Firewall. A implantação de rotas personalizadas para apontar o Firewall de outro hub seguro falhará e não será concluída com êxito. Por favor, considere converter esses hubs em hubs seguros com seus próprios firewalls.

Que cliente suporta a VPN (ponto a site) do Utilizador WAN Virtual do Azure?

A WAN Virtual suporta o cliente VPN do Azure, o Cliente OpenVPN ou qualquer cliente IKEv2. A autenticação do Microsoft Entra é suportada com o Cliente VPN do Azure. É necessário um mínimo de Windows 10 client OS versão 17763.0 ou superior. O(s) cliente(s) OpenVPN pode(m) suportar autenticação baseada em certificado. Assim que a autenticação baseada em certificado for selecionada no gateway, você verá o arquivo .ovpn* para baixar para o seu dispositivo. O IKEv2 suporta autenticação de certificado e RADIUS.

Para VPN de usuário (ponto a site) - por que o pool de clientes P2S é dividido em duas rotas?

Cada gateway tem duas instâncias. A divisão acontece para que cada instância de gateway possa alocar de forma independente IPs de cliente para clientes conectados e o tráfego da rede virtual seja roteado de volta para a instância de gateway correta para evitar salto de instância entre gateways.

Como faço para adicionar servidores DNS para clientes P2S?

Há duas opções para adicionar servidores DNS para os clientes P2S. O primeiro método é preferido, pois adiciona os servidores DNS personalizados ao gateway em vez do cliente.

1. Use o seguinte script do PowerShell para adicionar os servidores DNS personalizados. Substitua os valores do seu ambiente.

   // 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. Ou, se estiver usando o Cliente VPN do Azure para Windows 10, você pode modificar o arquivo XML de perfil baixado e adicionar as <tags dnsservers><dnsserver<>/dnsserver></dnsservers> antes de importá-lo.

      <azvpnprofile>
      <clientconfig>
   
          <dnsservers>
              <dnsserver>x.x.x.x</dnsserver>
              <dnsserver>y.y.y.y</dnsserver>
          </dnsservers>
   
      </clientconfig>
      </azvpnprofile>
   

Na VPN (ponto a site) do Utilizador – quantos clientes são suportados?

A tabela abaixo descreve o número de conexões simultâneas e a taxa de transferência agregada do gateway VPN ponto a site suportado em unidades de escala diferentes.

Unidade de Escala	Instâncias de gateway	Conexões simultâneas suportadas	Taxa de transferência agregada
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 libras esterlinas
7	2	5000	3,5 Gbps
8	2	5000	4 libras esterlinas
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 libras esterlinas
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	20 000	20 Gbps
60	6	30000	30 Gbps
80	8	40000	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	90000	90 Gbps
200	20	100000	100 Gbps

Por exemplo, digamos que o usuário escolha 1 unidade de escala. Cada unidade de escala implicaria um gateway ativo-ativo implantado e cada uma das instâncias (neste caso 2) suportaria até 500 conexões. Como você pode obter 500 conexões * 2 por gateway, isso não significa que você planeja 1000 em vez das 500 para essa unidade de escala. As instâncias podem precisar de manutenção durante as quais a conectividade para os 500 extras pode ser interrompida se você ultrapassar a contagem de conexões recomendada.

Para gateways com unidades de escala maiores que 20, pares adicionais altamente disponíveis de instâncias de gateway são implantados para fornecer capacidade adicional para conectar usuários. Cada par de instâncias suporta até 10.000 usuários adicionais. Por exemplo, se você implantar um Gateway com 100 unidades de escala, 5 pares de gateway (10 instâncias totais) serão implantados e até 50.000 (10.000 usuários x 5 pares de gateway) usuários simultâneos poderão se conectar.

Além disso, certifique-se de planejar o tempo de inatividade caso decida aumentar ou diminuir a escala na unidade de escala ou alterar a configuração ponto a site no gateway VPN.

Para VPN de Usuário (ponto a site) o aplicativo registrado da Microsoft na Autenticação de ID Entra é suportado?

Sim, o aplicativo registrado pela Microsoft é suportado na WAN Virtual. Você pode migrar sua VPN de usuário de aplicativo registrado manualmente para aplicativo registrado pela Microsoft para uma conectividade mais segura.

O que são unidades de escala de gateway de WAN Virtual?

Uma unidade de escala é uma unidade definida para escolher uma taxa de transferência agregada de um gateway no hub virtual. 1 unidade de escala de VPN = 500 Mbps. 1 unidade de escala de ExpressRoute = 2 Gbps. Exemplo: 10 unidade de escala de VPN implicaria 500 Mbps * 10 = 5 Gbps.

Qual é a diferença entre um gateway de rede virtual do Azure (Gateway VPN) e um gateway VPN WAN Virtual do Azure?

A WAN Virtual oferece conectividade site a site em grande escala e foi criada para débito, escalabilidade e facilidade de utilização. Quando você conecta um site a um gateway VPN WAN virtual, ele é diferente de um gateway de rede virtual comum que usa um tipo de gateway 'VPN site a site'. Quando você deseja conectar usuários remotos à WAN Virtual, use um tipo de gateway 'VPN ponto a site'. Os gateways VPN ponto a site e site a site são entidades separadas no hub WAN Virtual e devem ser implantados individualmente. Da mesma forma, quando você conecta um circuito de Rota Expressa a um hub de WAN Virtual, ele usa um recurso diferente para o gateway de Rota Expressa do que o gateway de rede virtual regular que usa o tipo de gateway 'Rota Expressa'.

A WAN virtual suporta taxa de transferência agregada de até 20 Gbps para VPN e ExpressRoute. A Virtual WAN também tem automação para conectividade com um ecossistema de parceiros de dispositivos de filial CPE. Os dispositivos de ramificação CPE têm automação interna que provisiona automaticamente e se conecta à WAN Virtual do Azure. Estes dispositivos estão disponíveis num ecossistema crescente de parceiros de SD-WAN e de VPN. Consulte a lista de parceiros preferenciais.

Qual é a diferença entre a WAN Virtual e um gateway de rede virtual do Azure?

Uma VPN de gateway de rede virtual é limitada a 100 túneis. Para as conexões, deve utilizar a WAN Virtual para uma VPN de grande escala. Você pode conectar até 1.000 conexões de filial por hub virtual com um agregado de 20 Gbps por hub. Uma ligação é um túnel ativo-ativo do dispositivo VPN no local para o hub virtual. Você também pode ter vários hubs virtuais por região, o que significa que você pode conectar mais de 1.000 filiais a uma única Região do Azure implantando vários hubs WAN Virtuais nessa Região do Azure, cada um com seu próprio gateway VPN site a site.

Qual é o algoritmo recomendado e os pacotes por segundo por instância site a site no hub WAN virtual? Quantos túneis há suporte por instância? Qual é a taxa de transferência máxima suportada em um único túnel?

A WAN virtual suporta 2 instâncias ativas de gateway VPN site a site em um hub virtual. Isso significa que há 2 conjuntos ativos-ativos de instâncias de gateway VPN em um hub virtual. Durante as operações de manutenção, cada instância é atualizada uma a uma, devido à qual um usuário pode experimentar uma breve diminuição na taxa de transferência agregada de um gateway VPN.

Embora a VPN WAN Virtual suporte muitos algoritmos, nossa recomendação é GCMAES256 para criptografia IPSEC e integridade para um desempenho ideal. AES256 e SHA256 são considerados de menor desempenho e, portanto, a degradação do desempenho, como latência e quedas de pacotes, pode ser esperada para tipos de algoritmos semelhantes.

Pacotes por segundo ou PPS é um fator do total # de pacotes e da taxa de transferência suportada por instância. Isto é melhor entendido com um exemplo. Digamos que uma instância de gateway VPN site a site de 1 unidade de escala de 500 Mbps seja implantada em um hub WAN virtual. Supondo um tamanho de pacote de 1400, PPS esperado para essa instância de gateway vpn em um máximo = [(500 Mbps * 1024 * 1024) /8/1400] ~ 47000.

Virtual WAN tem conceitos de conexão VPN, conexão de link e túneis. Uma única conexão VPN consiste em conexões de link. A WAN virtual suporta até 4 conexões de link em uma conexão VPN. Cada conexão de link consiste em dois túneis IPsec que terminam em duas instâncias de um gateway VPN ativo-ativo implantado em um hub virtual. O número total de túneis que podem ser encerrados em uma única instância ativa é 1000, o que também implica que a taxa de transferência para 1 instância estará disponível agregada em todos os túneis que se conectam a essa instância. Cada túnel também tem determinados valores de taxa de transferência. Em casos de vários túneis conectados a um gateway de unidade de escala de menor valor, é melhor avaliar a necessidade por túnel e planejar um gateway VPN que seja um valor agregado para taxa de transferência em todos os túneis que terminam na instância VPN.

Valores para várias unidades de escala suportadas na WAN Virtual

Unidade de escala	Taxa de transferência máxima por túnel (Mbps)	PPS máximo por túnel	Taxa de transferência máxima por instância (Mbps)	PPS máximo por instância
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	6.000	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	796 MIL
18	2300	215K	9000	843K
19	2300	215K	9500	889K
20	2300	215K	10000	936K

Nota

Todos os números são baseados no algoritmo GCM.

Quais provedores de dispositivos (parceiros de WAN virtual) são suportados?

Atualmente, muitos parceiros suportam a experiência de WAN Virtual totalmente automatizada. Para obter mais informações, veja Parceiros de WAN Virtual.

Quais são os passos de automatização dos parceiros da WAN Virtual?

Para obter os passos de automatização, veja Automatização dos parceiros da WAN Virtual.

Sou obrigado a utilizar um dispositivo de parceiro preferencial?

N.º Pode utilizar qualquer dispositivo compatível com VPN que cumpra os requisitos para suporte de IPsec de IKEv2/IKEv1. A WAN Virtual também tem soluções de parceiros CPE que automatizam a conectividade com a WAN Virtual do Azure, facilitando a configuração de conexões VPN IPsec em escala.

Como é que os parceiros de WAN Virtual automatizam a conectividade com a WAN Virtual do Azure?

As soluções de conectividade definida pelo software gerem, normalmente, os respetivos dispositivos de ramo com um controlador ou um centro de aprovisionamento de dispositivos. O controlador pode utilizar APIs do Azure para automatizar a conectividade à WAN Virtual do Azure. A automação inclui carregar informações de filial, baixar a configuração do Azure, configurar túneis IPsec em hubs virtuais do Azure e configurar automaticamente a conectividade do dispositivo de filial para a WAN Virtual do Azure. Quando você tem centenas de filiais, conectar-se usando Parceiros CPE de WAN Virtual é fácil porque a experiência de integração elimina a necessidade de configurar, configurar e gerenciar a conectividade IPsec em grande escala. Para mais informações, veja Automatização de parceiro de WAN Virtual.

E se um dispositivo que estou a utilizar não estiver na lista de parceiros da WAN Virtual? Ainda posso usá-lo para me conectar à VPN WAN Virtual do Azure?

Sim, desde que o dispositivo suporte IPsec IKEv1 ou IKEv2. Os parceiros de WAN virtual automatizam a conectividade do dispositivo para os pontos finais da VPN do Azure. Isso implica automatizar etapas como 'upload de informações de filial', 'IPsec e configuração' e 'conectividade'. Como seu dispositivo não é de um ecossistema de parceiros de WAN Virtual, você precisará fazer o trabalho pesado de pegar manualmente a configuração do Azure e atualizar seu dispositivo para configurar a conectividade IPsec.

Como é que os novos parceiros que não estão listados na sua lista de parceiros de lançamento são integrados?

Todas as APIs WAN virtuais são OpenAPI. Você pode examinar a documentação Virtual WAN partner automation para avaliar a viabilidade técnica. Um parceiro ideal é o que tem um dispositivo que pode ser aprovisionado para a conectividade IKEv1 ou IKEv2 IPsec. Uma vez que a empresa tenha concluído o trabalho de automação para seu dispositivo CPE com base nas diretrizes de automação fornecidas acima, você pode entrar em contato para azurevirtualwan@microsoft.com ser listado aqui Conectividade através de parceiros. Se você é um cliente que gostaria que uma determinada solução da empresa fosse listada como um parceiro de WAN Virtual, peça à empresa que entre em contato com a WAN Virtual enviando um e-mail para azurevirtualwan@microsoft.com.

Como a WAN Virtual está suportando dispositivos SD-WAN?

Os parceiros de WAN virtual automatizam a conectividade IPsec para pontos finais de VPN do Azure. Se o parceiro de WAN Virtual for um provedor de SD-WAN, estará implícito que o controlador SD-WAN gerencia a automação e a conectividade IPsec com os pontos finais da VPN do Azure. Se o dispositivo SD-WAN exigir seu próprio ponto de extremidade em vez da VPN do Azure para qualquer funcionalidade proprietária da SD-WAN, você poderá implantar o ponto de extremidade SD-WAN em uma rede virtual do Azure e coexistir com a WAN Virtual do Azure.

A WAN virtual suporta emparelhamento BGP e também tem a capacidade de implantar NVAs em um hub WAN virtual.

Quantos dispositivos VPN podem se conectar a um único hub?

Até 1.000 conexões são suportadas por hub virtual. Cada conexão consiste em quatro links e cada conexão de link suporta dois túneis que estão em uma configuração ativa-ativa. Os túneis terminam em um gateway VPN de hub virtual do Azure. Os links representam o link físico do ISP na filial/dispositivo VPN.

O que é uma conexão de filial com a WAN Virtual do Azure?

Uma conexão de uma filial ou dispositivo VPN na WAN Virtual do Azure é uma conexão VPN que conecta virtualmente o site VPN e o gateway VPN do Azure em um hub virtual.

O que acontece se o dispositivo VPN local tiver apenas 1 túnel para um gateway de VPN WAN Virtual do Azure?

Uma conexão WAN Virtual do Azure é composta por 2 túneis. Um gateway VPN WAN virtual é implantado em um hub virtual no modo ativo-ativo, o que implica que há túneis separados de dispositivos locais terminando em instâncias separadas. Esta é a recomendação para todos os utilizadores. No entanto, se o usuário optar por ter apenas 1 túnel para uma das instâncias do gateway VPN WAN Virtual, se por qualquer motivo (manutenção, patches, etc.) a instância do gateway for colocada offline, o túnel será movido para a instância ativa secundária e o usuário poderá experimentar uma reconexão. As sessões BGP não serão movidas entre instâncias.

O que acontece durante uma redefinição de gateway em um gateway VPN WAN Virtual?

O botão Redefinição de Gateway deve ser usado se todos os dispositivos locais estiverem funcionando conforme o esperado, mas a conexão VPN site a site no Azure estiver em um estado Desconectado. Os gateways VPN de WAN virtual são sempre implantados em um estado Ativo-Ativo para alta disponibilidade. Isso significa que sempre há mais de uma instância implantada em um gateway VPN a qualquer momento. Quando o botão Redefinição de Gateway é usado, ele reinicializa as instâncias no gateway VPN de forma sequencial para que suas conexões não sejam interrompidas. Haverá um breve intervalo à medida que as conexões passarem de uma instância para outra, mas essa lacuna deve ser inferior a um minuto. Além disso, observe que a redefinição dos gateways não alterará seus IPs públicos.

Esse cenário só se aplica às conexões S2S.

O dispositivo VPN local pode se conectar a vários hubs?

Sim. O fluxo de tráfego, ao começar, é do dispositivo local para a borda de rede Microsoft mais próxima e, em seguida, para o hub virtual.

Existem novos recursos do Resource Manager disponíveis para a WAN Virtual?

Sim, a WAN Virtual tem novos recursos do Resource Manager. Para obter mais informações, consulte Descrição Geral.

Posso implantar e usar meu dispositivo virtual de rede favorito (em uma rede virtual NVA) com a WAN Virtual do Azure?

Sim, você pode conectar sua rede virtual de dispositivo virtual de rede (NVA) favorita à WAN Virtual do Azure.

Posso criar um dispositivo virtual de rede dentro do hub virtual?

Um Network Virtual Appliance (NVA) pode ser implantado dentro de um hub virtual. Para conhecer as etapas, consulte Sobre NVAs em um hub WAN virtual.

Uma VNet falada pode ter um gateway de rede virtual?

N.º A VNet spoke não pode ter um gateway de rede virtual se estiver conectada ao hub virtual.

Uma VNet falada pode ter um Servidor de Rotas do Azure?

N.º A VNet spoke não pode ter um Route Server se estiver conectada ao hub WAN virtual.

Existe suporte para BGP na conectividade VPN?

Sim, o BGP é suportado. Ao criar um site VPN, você pode fornecer os parâmetros BGP nele. Isso implica que todas as conexões criadas no Azure para esse site serão habilitadas para BGP.

Existem informações de licenciamento ou de preços da WAN Virtual?

Sim. Veja a página Preços.

É possível construir uma WAN Virtual do Azure com um modelo do Resource Manager?

Uma configuração simples de uma WAN Virtual com um hub e um vpnsite pode ser criada usando um modelo de início rápido. A WAN virtual é principalmente um serviço REST ou orientado por portal.

As VNets spoke conectadas a um hub virtual podem se comunicar entre si (V2V Transit)?

Sim. A WAN Virtual Padrão suporta conectividade transitiva VNet-to-VNet através do hub WAN Virtual ao qual as VNets estão conectadas. Na terminologia da WAN virtual, nos referimos a esses caminhos como "trânsito VNet WAN virtual local" para VNets conectadas a um hub WAN virtual dentro de uma única região e "trânsito VNet WAN virtual global" para VNets conectadas por meio de vários hubs WAN virtual em duas ou mais regiões.

Em alguns cenários, as VNets spoke também podem ser emparelhadas diretamente umas com as outras usando emparelhamento de rede virtual, além do trânsito VNet WAN virtual local ou global. Nesse caso, o emparelhamento VNet tem precedência sobre a conexão transitiva por meio do hub WAN virtual.

A conectividade entre ramificações é permitida na WAN Virtual?

Sim, a conectividade entre ramificações está disponível na WAN Virtual. A ramificação é conceitualmente aplicável a sites VPN, circuitos de Rota Expressa ou usuários de VPN ponto-a-site/usuário. A habilitação de ramificação para ramificação é habilitada por padrão e pode ser localizada nas definições de configuração da WAN. Isso permite que filiais/usuários VPN se conectem a outras filiais VPN e a conectividade de trânsito também é habilitada entre usuários VPN e ExpressRoute.

O tráfego de filial para filial atravessa a WAN Virtual do Azure?

Sim. O tráfego de filial a filial atravessa a WAN Virtual do Azure.

A WAN Virtual requer a Rota Expressa de cada site?

N.º A WAN virtual não requer a Rota Expressa de cada site. Seus sites podem estar conectados a uma rede de provedores usando um circuito de Rota Expressa. Para sites conectados usando a Rota Expressa a um hub virtual e VPN IPsec no mesmo hub, o hub virtual fornece conectividade de trânsito entre a VPN e o usuário da Rota Expressa.

Existe uma taxa de transferência de rede ou limite de conexão ao usar a WAN Virtual do Azure?

A taxa de transferência de rede é por serviço em um hub WAN virtual. Em cada hub, a taxa de transferência agregada de VPN é de até 20 Gbps, a taxa de transferência agregada de Rota Expressa é de até 20 Gbps e a taxa de transferência agregada de VPN de usuário/ponto a site é de até 200 Gbps. O roteador no hub virtual suporta até 50 Gbps para fluxos de tráfego VNet-to-VNet e assume um total de 2000 cargas de trabalho VM em todas as VNets conectadas a um único hub virtual.

Para garantir a capacidade inicial sem ter que esperar que o hub virtual se expanda quando mais taxa de transferência for necessária, você pode definir a capacidade mínima ou modificar conforme necessário. Consulte Sobre configurações de hub virtual - capacidade do hub. Para implicações de custo, consulte Custo unitário da infraestrutura de roteamento na página Preços da WAN Virtual do Azure.

Quando os sites VPN se conectam a um hub, eles o fazem com conexões. A WAN virtual suporta até 1000 conexões ou 2000 túneis IPsec por hub virtual. Quando os usuários remotos se conectam ao hub virtual, eles se conectam ao gateway VPN P2S, que suporta até 100.000 usuários, dependendo da unidade de escala (largura de banda) escolhida para o gateway VPN P2S no hub virtual.

Posso usar o NAT-T nas minhas conexões VPN?

Sim, a travessia NAT (NAT-T) é suportada. O gateway VPN WAN Virtual NÃO executará nenhuma funcionalidade semelhante a NAT nos pacotes internos de/para os túneis IPsec. Nessa configuração, verifique se o dispositivo local inicia o túnel IPsec.

Como posso configurar uma unidade de escala para uma configuração específica, como 20 Gbps?

Vá para o gateway VPN dentro de um hub no portal e, em seguida, clique na unidade de escala para alterá-la para a configuração apropriada.

A WAN Virtual permite que o dispositivo local utilize vários ISPs em paralelo ou é sempre um único túnel VPN?

As soluções de dispositivo local podem aplicar políticas de tráfego para direcionar o tráfego através de vários túneis para o hub WAN Virtual do Azure (gateway VPN no hub virtual).

O que é arquitetura de trânsito global?

Para obter informações, consulte Arquitetura de rede de trânsito global e WAN virtual.

Como é que o tráfego é encaminhado no backbone do Azure?

O tráfego segue o padrão: branch device -ISP-Microsoft> network edge-Microsoft> DC (hub VNet)->Microsoft network edge-ISP-branch>> device>

Neste modelo, do que precisa em cada site? Apenas uma ligação à internet?

Sim. Uma ligação à Internet e um dispositivo físico que suporte IPsec, de preferência dos nossos parceiros WAN virtuais integrados. Opcionalmente, pode gerir manualmente a configuração e a conectividade com o Azure a partir do seu dispositivo preferido.

Como faço para habilitar a rota padrão (0.0.0.0/0) para uma conexão (VPN, Rota Expressa ou rede virtual)?

Um hub virtual pode propagar uma rota padrão aprendida para uma conexão VPN/Rota Expressa de rede virtual/site a site se o sinalizador estiver 'Habilitado' na conexão. Esse sinalizador fica visível quando o usuário edita uma conexão de rede virtual, uma conexão VPN ou uma conexão de Rota Expressa. Por padrão, esse sinalizador é desativado quando um site ou um circuito de Rota Expressa está conectado a um hub. Ele é habilitado por padrão quando uma conexão de rede virtual é adicionada para conectar uma VNet a um hub virtual.

A rota padrão não se origina no hub WAN Virtual; a rota padrão será propagada se já tiver sido aprendida pelo hub WAN Virtual como resultado da implantação de um firewall no hub ou se outro site conectado tiver o encapsulamento forçado habilitado. Uma rota padrão não se propaga entre hubs (inter-hub).

É possível criar vários hubs WAN virtuais na mesma região?

Sim. Os clientes agora podem criar mais de um hub na mesma região para a mesma WAN Virtual do Azure.

Como o hub virtual em uma WAN virtual seleciona o melhor caminho para uma rota de vários hubs?

Para obter informações, consulte a página de preferências de roteamento do hub virtual.

O hub WAN Virtual permite conectividade entre circuitos de Rota Expressa?

O trânsito entre ER-to-ER é sempre através do alcance Global. Os gateways de hub virtual são implantados em regiões DC ou Azure. Quando dois circuitos ExpressRoute se conectam via alcance global, não há necessidade de o tráfego vir de todos os roteadores de borda para o DC do hub virtual.

Existe um conceito de peso nos circuitos de Rota Expressa da WAN Virtual do Azure ou nas conexões VPN

Quando vários circuitos de Rota Expressa são conectados a um hub virtual, o peso de roteamento na conexão fornece um mecanismo para que a Rota Expressa no hub virtual prefira um circuito sobre o outro. Não há nenhum mecanismo para definir um peso em uma conexão VPN. O Azure sempre prefere uma conexão de Rota Expressa a uma conexão VPN em um único hub.

A WAN Virtual prefere a Rota Expressa à VPN para o Azure de saída de tráfego

Sim. A WAN Virtual prefere a Rota Expressa à VPN para a saída de tráfego do Azure. No entanto, você pode configurar a preferência de roteamento do hub virtual para alterar a preferência padrão. Para conhecer as etapas, consulte Configurar preferência de roteamento de hub virtual.

Quando um hub WAN Virtual tem um circuito de Rota Expressa e um site VPN conectado a ele, o que faria com que uma rota de conexão VPN fosse preferida em relação à Rota Expressa?

Quando um circuito de Rota Expressa é conectado a um hub virtual, os roteadores do Microsoft Edge são o primeiro nó para comunicação entre o local e o Azure. Esses roteadores de borda se comunicam com os gateways de Rota Expressa da WAN Virtual que, por sua vez, aprendem rotas do roteador de hub virtual que controla todas as rotas entre quaisquer gateways na WAN Virtual. Os roteadores do Microsoft Edge processam rotas de Rota Expressa de hub virtual com maior preferência em relação às rotas aprendidas localmente.

Por qualquer motivo, se a conexão VPN se tornar o principal meio para o hub virtual aprender rotas (por exemplo, cenários de failover entre a Rota Expressa e a VPN), a menos que o site VPN tenha um comprimento de caminho AS maior, o hub virtual continuará a compartilhar rotas aprendidas de VPN com o gateway da Rota Expressa. Isso faz com que os roteadores do Microsoft Edge prefiram rotas VPN em vez de rotas locais.

O ExpressRoute suporta roteamento ECMP (Equal-Cost Multi-Path) na WAN Virtual?

Quando vários circuitos de Rota Expressa são conectados a um hub WAN Virtual, o ECMP permite que o tráfego de redes virtuais spoke para o local pela Rota Expressa seja distribuído em todos os circuitos de Rota Expressa que anunciam as mesmas rotas locais. Atualmente, o ECMP não está habilitado por padrão para hubs WAN virtuais.

Quando dois hubs (hub 1 e 2) estão conectados e há um circuito ExpressRoute conectado como uma gravata borboleta a ambos os hubs, qual é o caminho para uma VNet conectada ao hub 1 chegar a uma VNet conectada no hub 2?

O comportamento atual é preferir o caminho do circuito ExpressRoute em vez de hub-to-hub para conectividade VNet-to-VNet. No entanto, isso não é incentivado em uma configuração de WAN Virtual. Para resolver isso, você pode fazer uma das duas coisas:

• Configure vários circuitos de Rota Expressa (provedores diferentes) para se conectar a um hub e use a conectividade hub-to-hub fornecida pela WAN Virtual para fluxos de tráfego entre regiões.

• Configure o AS-Path como a preferência de roteamento de hub para seu hub virtual. Isso garante que o tráfego entre os 2 hubs passe pelo roteador de hub virtual em cada hub e use o caminho hub-to-hub em vez do caminho ExpressRoute (que atravessa os roteadores do Microsoft Edge). Para obter mais informações, veja Configurar a preferência de encaminhamento do hub virtual.

Quando há um circuito de Rota Expressa conectado como uma gravata borboleta a um hub WAN Virtual e uma VNet autônoma, qual é o caminho para a VNet autônoma chegar ao hub WAN Virtual?

Para novas implantações, essa conectividade é bloqueada por padrão. Para permitir essa conectividade, você pode habilitar essas alternâncias de gateway de Rota Expressa na folha "Editar hub virtual" e na folha "Gateway de rede virtual" no Portal. No entanto, é recomendável manter essas alternâncias desabilitadas e, em vez disso , criar uma conexão de Rede Virtual para conectar diretamente VNets autônomas a um hub WAN Virtual. Depois, o tráfego de VNet para VNet atravessará o roteador de hub WAN Virtual, que oferece melhor desempenho do que o caminho da Rota Expressa. O caminho da Rota Expressa inclui o gateway da Rota Expressa, que tem limites de largura de banda mais baixos do que o roteador do hub, bem como os roteadores Microsoft Enterprise Edge/MSEE, que é um salto extra no caminho de dados.

No diagrama abaixo, ambas as alternâncias precisam ser habilitadas para permitir a conectividade entre a VNet 4 autônoma e as VNets diretamente conectadas ao hub 2 (VNet 2 e VNet 3): Permitir tráfego de redes WAN virtuais remotas para o gateway de rede virtual e Permitir tráfego de redes WAN não virtuais para o gateway ExpressRoute do hub virtual. Se um Servidor de Rotas do Azure for implantado na VNet 4 autônoma e o Servidor de Rotas tiver ramificação para ramificação habilitada, a conectividade será bloqueada entre a VNet 1 e a VNet 4 autônoma.

Ativar ou desativar a alternância afetará apenas o seguinte fluxo de tráfego: tráfego fluindo entre o hub WAN Virtual e VNet(s) autônoma(s) através do circuito ExpressRoute. Ativar ou desativar a alternância não incorrerá em tempo de inatividade para todos os outros fluxos de tráfego (por exemplo, o site local para a VNet spoke 2 não será afetado, a VNet 2 para a VNet 3 não será afetada, etc.).

Por que a conectividade não funciona quando anuncio rotas com um ASN de 0 no AS-Path?

O hub WAN Virtual descarta rotas com um ASN de 0 no AS-Path. Para garantir que essas rotas sejam anunciadas com êxito no Azure, o AS-Path não deve incluir 0.

Os hubs podem ser criados em diferentes grupos de recursos na WAN Virtual?

Sim. Atualmente, essa opção está disponível somente via PowerShell. O portal da WAN Virtual requer que os hubs estejam no mesmo grupo de recursos que o próprio recurso da WAN Virtual.

Qual é o espaço de endereço de hub recomendado durante a criação do hub?

O espaço de endereço do hub WAN virtual recomendado é /23. O hub WAN virtual atribui sub-redes a vários gateways (Rota Expressa, VPN site a site, VPN ponto a site, Firewall do Azure, Roteador de hub virtual). Para cenários em que os NVAs são implantados dentro de um hub virtual, um /28 normalmente é esculpido para as instâncias NVA. No entanto, se o usuário provisionar vários NVAs, uma sub-rede /27 pode ser atribuída. Portanto, tendo em mente uma arquitetura futura, enquanto os hubs WAN virtuais são implantados com um tamanho mínimo de /24, o espaço de endereço de hub recomendado no momento da criação para a entrada do usuário é /23.

Existe suporte para IPv6 na WAN Virtual?

O IPv6 não é suportado no hub WAN Virtual e seus gateways. Se você tiver uma VNet que tenha suporte a IPv4 e IPv6 e quiser conectar a VNet à WAN Virtual, esse cenário não é suportado no momento.

Para o cenário de VPN de usuário ponto a site com fuga de internet via Firewall do Azure, você provavelmente terá que desativar a conectividade IPv6 em seu dispositivo cliente para forçar o tráfego para o hub WAN Virtual. Isso ocorre porque os dispositivos modernos, por padrão, usam endereços IPv6.

Qual é a versão de API recomendada para ser usada por scripts que automatizam várias funcionalidades da WAN Virtual?

É necessária uma versão mínima de 05-01-2022 (1 de maio de 2022).

Existem limites de WAN Virtual?

Consulte a seção Limites de WAN virtual na página Limites de assinatura e serviço.

Quais são as diferenças entre os tipos de WAN Virtual (Basic e Standard)?

Consulte WANs virtuais básicas e padrão. Para saber os preços, consulte a página Preços .

A WAN Virtual armazena dados de clientes?

N.º A WAN virtual não armazena dados de clientes.

Existem Provedores de Serviços Gerenciados que podem gerenciar a WAN Virtual para usuários como um serviço?

Sim. Para obter uma lista de soluções de Provedor de Serviços Gerenciados (MSP) habilitadas por meio do Azure Marketplace, consulte Ofertas do Azure Marketplace por parceiros MSP do Azure Networking.

Qual é a diferença entre o roteamento do hub WAN Virtual e o Servidor de Rotas do Azure em uma rede virtual?

O hub WAN Virtual do Azure e o Azure Route Server fornecem recursos de emparelhamento BGP (Border Gateway Protocol) que podem ser utilizados por NVAs (Network Virtual Appliance) para anunciar endereços IP do NVA para as redes virtuais do Azure do usuário. As opções de implantação diferem no sentido de que o Azure Route Server normalmente é implantado por uma VNet de hub do cliente autogerenciada, enquanto a WAN Virtual do Azure fornece um serviço de hub de malha total de zero toque ao qual os clientes conectam seus vários pontos finais de raios (Azure VNet, filiais locais com VPN site a site ou SDWAN, usuários remotos com VPN de usuário ponto-a-site/remoto e conexões privadas com a Rota Expressa) e desfrutam do emparelhamento BGP para NVAs implantados na VNet spoke junto com outros vWAN recursos como conectividade de trânsito para VNet-to-VNet, conectividade de trânsito entre VPN e ExpressRoute, roteamento personalizado/avançado, associação e propagação de rota personalizada, intenção/políticas de roteamento para segurança entre regiões sem problemas, firewall Secure Hub/Azure etc. Para obter mais detalhes sobre o emparelhamento BGP da WAN Virtual, consulte Como emparelhar BGP com um hub virtual.

Se estiver a utilizar um fornecedor de segurança de terceiros (Zscaler, iBoss ou Checkpoint) para proteger o meu tráfego de Internet, por que não vejo o site VPN associado ao fornecedor de segurança de terceiros no portal do Azure?

Quando você opta por implantar um provedor de parceiro de segurança para proteger o acesso à Internet para seus usuários, o provedor de segurança de terceiros cria um site VPN em seu nome. Como o provedor de segurança de terceiros é criado automaticamente pelo provedor e não é um site VPN criado pelo usuário, esse site VPN não aparecerá no portal do Azure.

Para obter mais informações sobre as opções disponíveis de provedores de segurança de terceiros e como configurá-lo, consulte Implantar um provedor de parceiro de segurança.

As comunidades BGP geradas pelo local serão preservadas na WAN Virtual?

Sim, as comunidades BGP geradas pelo local serão preservadas na WAN Virtual.

As comunidades BGP geradas por pares BGP (em uma rede virtual anexada) serão preservadas na WAN virtual?

Sim, as comunidades BGP geradas por Peers BGP serão preservadas na WAN Virtual. As comunidades são preservadas no mesmo hub e nas conexões interhub. Isso também se aplica a cenários de WAN virtual usando políticas de intenção de roteamento.

Quais números ASN são suportados para redes locais conectadas remotamente que executam BGP?

Você pode usar seus próprios ASNs públicos ou privados para suas redes locais. Não é possível usar os intervalos reservados pelo Azure ou IANA:

• ASNs reservados pelo Azure:
  • ASNs públicos: 8074, 8075, 12076
  • ASNs privados: 65515, 65517, 65518, 65519, 65520
  • ASNs reservados pela IANA: 23456, 64496-64511, 65535-65551

Existe uma maneira de alterar o ASN para um gateway VPN?

N.º A WAN virtual não suporta alterações ASN para gateways VPN.

Na WAN Virtual, o que são os desempenhos estimados pelo SKU do gateway do ExpressRoute?

Unidade de escala	Conexões por segundo	Mega-Bits por segundo	Pacotes por segundo
1 unidade de escala	14 000	2.000	200,000
2 unidades de escala	28,000	4,000	400,000
3 unidades de escala	42,000	6000	600,000
4 unidades de escala	56,000	8,000	800,000
5 unidades de escala	70,000	10,000	1 000 000
6 unidades de escala	84,000	12.000	1,200,000
7 unidades de escala	98,000	14 000	1,400,000
8 unidades de escala	112,000	16 000	1,600,000
9 unidades de escala	126,000	18 000	1,800,000
10 unidades de escala	140,000	20.000	2,000,000

Dimensione as unidades de 2 a 10, durante as operações de manutenção, mantenha o rendimento agregado. No entanto, a unidade de escala 1, durante uma operação de manutenção, pode ver uma ligeira variação nos números de rendimento.

Se eu conectar um circuito Local de Rota Expressa a um hub WAN Virtual, só poderei acessar regiões no mesmo local de metrô que o circuito Local?

Os circuitos locais só podem ser conectados a gateways de Rota Expressa em sua região correspondente do Azure. No entanto, não há limitação para rotear o tráfego para redes virtuais faladas em outras regiões.

Por que o roteador de hub virtual requer um endereço IP público com portas abertas?

Esses pontos de extremidade públicos são necessários para que o SDN subjacente e a plataforma de gerenciamento do Azure se comuniquem com o roteador de hub virtual. Como o roteador de hub virtual é considerado parte da rede privada do cliente, a plataforma subjacente do Azure não consegue acessar e gerenciar diretamente o roteador de hub por meio de seus pontos de extremidade privados devido aos requisitos de conformidade. A conectividade com os pontos de extremidade públicos do roteador de hub é autenticada por meio de certificados, e o Azure realiza auditorias de segurança de rotina desses pontos de extremidade públicos. Como resultado, eles não constituem uma exposição de segurança do seu hub virtual.

Existe um limite de rota para clientes OpenVPN que se conectam a um gateway de VPN P2S do Azure?

O limite de rota para clientes OpenVPN é 1000.

Como é calculado o SLA da WAN Virtual?

A Virtual WAN é uma plataforma de rede como serviço que tem um SLA de 99,95%. No entanto, a WAN Virtual combina muitos componentes diferentes, como o Firewall do Azure, VPN site a site, Rota Expressa, VPN ponto a site e Hub de WAN Virtual/Dispositivos Virtuais de Rede Integrada.

O SLA para cada componente é calculado individualmente. Por exemplo, se a Rota Expressa tiver um tempo de inatividade de 10 minutos, a disponibilidade da Rota Expressa será calculada como (Máximo de Minutos Disponíveis - tempo de inatividade) / Máximo de Minutos Disponíveis * 100.

Você pode alterar o espaço de endereço da VNet em uma VNet falada conectada ao hub?

Sim, isso pode ser feito automaticamente, sem necessidade de atualização ou redefinição na conexão de emparelhamento. Tenha em atenção o seguinte:

• Não é necessário clicar no botão "Sincronizar" na folha Emparelhamento. Depois que o espaço de endereço da VNet for alterado, o emparelhamento da VNet será sincronizado automaticamente com a VNet do hub virtual.
• Certifique-se de que o espaço de endereço atualizado não se sobreponha ao espaço de endereço para quaisquer VNets spoke existentes na sua WAN Virtual.

Você pode encontrar mais informações sobre como alterar o espaço de endereço VNet aqui.

Qual é o número máximo de endereços de rede virtual spoke suportados para hubs configurados com intenção de roteamento?

O número máximo de espaços de endereço em todas as Redes Virtuais diretamente conectadas a um único hub WAN Virtual é 400. Esse limite é aplicado individualmente a cada hub de WAN Virtual em uma implantação de WAN Virtual. Os espaços de endereço de rede virtual conectados a hubs remotos (outros hubs WAN virtuais na mesma WAN virtual) não são contados para esse limite.

Este limite é ajustável. Para obter mais informações sobre o limite, o procedimento para solicitar um aumento de limite e scripts de exemplo para determinar o número de espaços de endereço em Redes Virtuais conectadas a um hub WAN Virtual, consulte Limites de espaço de endereço de rede virtual com intenção de roteamento.

Manutenção de gateway controlado pelo cliente de WAN virtual

Quais serviços estão incluídos no escopo Configuração de Manutenção de Gateways de Rede?

Para WAN Virtual, você pode configurar janelas de manutenção para gateways VPN site a site e gateways de Rota Expressa.

Que manutenção é suportada ou não pela manutenção controlada pelo cliente?

Os serviços do Azure passam por atualizações de manutenção periódicas para melhorar a funcionalidade, a confiabilidade, o desempenho e a segurança. Depois de configurar uma janela de manutenção para seus recursos, a manutenção do SO convidado e do serviço é executada durante essa janela. Essas atualizações são responsáveis pela maioria dos itens de manutenção que causam preocupação para os clientes.

As atualizações de hardware de host subjacente e de infraestrutura de datacenter não são cobertas pela manutenção controlada pelo cliente. Além disso, se houver um problema de segurança de alta gravidade que possa colocar em risco nossos clientes, o Azure pode precisar substituir o controle do cliente da janela de manutenção e implantar a alteração. Estas são ocorrências raras que só seriam usadas em casos extremos.

Posso receber uma notificação antecipada da manutenção?

No momento, a notificação avançada não pode ser habilitada para a manutenção dos recursos do Gateway de Rede.

Posso configurar uma janela de manutenção inferior a cinco horas?

Neste momento, você precisa configurar uma janela mínima de cinco horas no seu fuso horário preferido.

Posso configurar um cronograma de manutenção que não se repita diariamente?

Neste momento, você precisa configurar uma janela de manutenção diária.

Os recursos de Configuração de Manutenção precisam estar na mesma região que o recurso de gateway?

Sim.

Preciso implantar uma unidade de escala mínima de gateway para ser elegível para manutenção controlada pelo cliente?

N.º

Quanto tempo leva para que a política de configuração de manutenção entre em vigor depois de ser atribuída ao recurso de gateway?

Pode levar até 24 horas para que os Gateways de Rede sigam o cronograma de manutenção depois que a política de manutenção for associada ao recurso de gateway.

Como devo planejar as janelas de manutenção ao usar VPN e ExpressRoute em um cenário de coexistência?

Ao trabalhar com VPN e ExpressRoute em um cenário de coexistência ou sempre que você tiver recursos atuando como backups, recomendamos a configuração de janelas de manutenção separadas. Essa abordagem garante que a manutenção não afete seus recursos de backup ao mesmo tempo.

Agendei uma janela de manutenção para uma data futura para um dos meus recursos. As atividades de manutenção serão pausadas neste recurso até lá?

Não, as atividades de manutenção não serão pausadas no seu recurso durante o período anterior à janela de manutenção agendada. Para os dias não cobertos no seu cronograma de manutenção, a manutenção continua como de costume no recurso.

Existem limites para o número de rotas que posso anunciar?

Sim, há limites. O ExpressRoute suporta até 4.000 prefixos para emparelhamento privado e 200 prefixos para emparelhamento Microsoft. Com o ExpressRoute Premium, você pode aumentar o limite para 10.000 rotas para emparelhamento privado. O número máximo de rotas anunciadas a partir do emparelhamento privado do Azure por meio de um Gateway de Rota Expressa em um circuito de Rota Expressa é de 1.000, que é o mesmo para circuitos de Rota Expressa padrão e premium. Para obter mais detalhes, você pode revisar os circuitos de Rota Expressa Limites de Rota na página Limites de assinatura e cotas do Azure Observe que os anúncios de rota IPv6 não são suportados atualmente com a WAN Virtual.

Existem restrições sobre intervalos de IP que posso anunciar durante a sessão BGP?

Sim, há restrições. Prefixos privados (RFC1918) não são aceitos para a sessão BGP de emparelhamento da Microsoft. No entanto, qualquer tamanho de prefixo até um prefixo /32 é aceito no emparelhamento privado e da Microsoft.

O que acontece se o limite de rota BGP for excedido?

Se o limite de rota BGP for excedido, as sessões BGP serão desconectadas. As sessões serão restauradas assim que a contagem de prefixos for reduzida abaixo do limite. Para obter mais informações, consulte os Limites de rota dos circuitos de Rota Expressa na página Limites de assinatura e cotas do Azure.

Posso monitorar o número de rotas anunciadas ou recebidas em um circuito de Rota Expressa?

Sim, pode. Para obter as práticas recomendadas e a configuração para monitoramento de alertas baseado em métricas, consulte as práticas recomendadas de monitoramento do Azure.

Qual é a recomendação para reduzir o número de prefixos IP?

Recomendamos agregar os prefixos antes de anunciá-los na Rota Expressa ou no gateway VPN. Além disso, você pode usar Mapas de Rotas para resumir rotas anunciadas de/para a WAN Virtual.

Posso usar tabelas de rotas definidas pelo usuário em redes virtuais spoke conectadas ao hub WAN virtual?

Sim. As rotas que o hub WAN Virtual anuncia para recursos implantados em Redes Virtuais conectadas são rotas do tipo Border Gatway Protocol (BGP). Se uma tabela de rotas definida pelo usuário estiver associada a uma sub-rede conectada à WAN Virtual, a configuração "Propagar rotas de gateway" deverá ser definida como "Sim" para que a WAN Virtual anuncie os recursos implantados nessa sub-rede. A plataforma de rede subjacente definida por software do Azure usa o algoritmo a seguir para selecionar rotas com base no algoritmo de seleção de rotas do Azure.

Próximos passos

Para obter mais informações sobre a WAN Virtual, consulte Sobre a WAN Virtual.