Usar duas NICs na mesma sub‑rede no Windows Server 2019 (CCTV): métricas, rotas e melhores práticas

Depois de migrar para o Windows Server 2019, duas NICs na mesma sub‑rede podem “brigar” pela rota padrão e a aplicação de CCTV passa a usar só uma. Veja como diagnosticar e corrigir com métricas, rotas e boas práticas — sem depender de gambiarras.

Índice

Contexto e sintomas

Em ambientes de videovigilância (CCTV), é comum dedicar uma interface à receção de streams das câmaras e outra ao envio de vídeo para clientes, NVRs ou armazenamento. Após migrar de Windows Server 2012 R2 para 2019, muitos administradores percebem que apenas uma das NICs transmite/recebe tráfego, apesar de ambas estarem ativas e up no mesmo /24.

O problema raramente é um “bug” do Windows. É a lógica de seleção de rotas: o sistema sempre escolhe o caminho de menor custo para cada destino. Se duas interfaces pertencem à mesma sub‑rede e têm custos (métricas) parecidos, quase todo o tráfego sai pela que tiver menor métrica — e respostas também tendem a usar a mesma interface que resolveu a rota do destino.

Como o Windows decide por qual NIC enviar

De forma simplificada, o Windows avalia a tabela de rotas em busca do melhor match para o destino. Empate técnico? Ele desempata pela métrica da rota e, em seguida, pela métrica da interface. Com “Automatic Metric” habilitado, a métrica é calculada com base na velocidade do link — o que pode não refletir a sua intenção (separar fluxos por NIC).

Três consequências práticas ao manter duas NICs no mesmo segmento:

As duas interfaces anunciam rotas idênticas para a mesma rede; a de menor custo vence.
Se houver dois default gateways, o tráfego de saída fica imprevisível e a resolução de nome pode oscilar (clientes alcançam IP “errado”).
Broadcasts/ARP e difusão competem nos dois adaptadores, sem separação lógica de cargas.

Diagnóstico rápido

Conferir endereçamento e gateways
ipconfig /all Verifique se apenas uma NIC tem gateway padrão. Evite dois gateways no mesmo host.
Inspecionar a tabela de rotas e custos
route print Get-NetRoute | Sort-Object -Property DestinationPrefix,RouteMetric | Format-Table -Auto Get-NetIPInterface | Sort-Object InterfaceMetric | Format-Table InterfaceAlias,AddressFamily,AutomaticMetric,InterfaceMetric
Testar o caminho usado por origem específica
ping -S 192.168.10.10 192.168.10.50 Test-NetConnection -ComputerName 192.168.10.50 -SourceAddress 192.168.10.10 -InformationLevel Detailed tracert -d -S 192.168.10.10 8.8.8.8
Validar uso por placa no Performance Monitor: \Network Interface(*)\Bytes Total/sec, Output Queue Length e Packets Outbound Errors.
Checar a vinculação da aplicação (IP/placa): netstat -abno | findstr /i "LISTENING" Get-NetUDPEndpoint | Sort-Object LocalAddress,LocalPort | Format-Table

Soluções eficazes

A tabela resume as ações de maior impacto e por que funcionam:

Passo	Ação recomendada	Motivo/resultado esperado
Verificar ordem lógica e métrica	Desative Automatic Metric e atribua métricas distintas às NICs.	O Windows usa sempre a rota de menor custo; métricas distintas evitam empate.
Evitar duas NICs na mesma sub‑rede	Separe por VLAN/sub‑rede (ex.: 192.168.10.0/24 câmaras; 192.168.20.0/24 clientes).	Elimina competição de rotas e facilita aplicar políticas e QoS.
Ajustar/adicionar rotas estáticas	Direcione redes/hosts específicos para a NIC correta com rotas persistentes.	Força o tráfego certo a sair pela interface desejada, mesmo no mesmo L2.
NIC Teaming	Se a meta for redundância/banda, use teaming e apresente um adaptador lógico.	Simplifica configuração da aplicação e evita assimetrias de rota.
Drivers/firmware	Atualize controladores e avalie offloads (RSS/RSC/LSO) se houver perda de pacotes.	Compatibilidade e estabilidade pós‑migração.
Definições da aplicação	Confirme IP/adapter vinculados no software de CCTV.	Alguns sistemas gravam o GUID/IPv4 antigo e não se autoatualizam.

Ajustar métrica de interface e desativar “Automatic Metric”

Pelo GUI: ncpa.cpl ▸ clique com o botão direito na NIC ▸ Properties ▸ selecione Internet Protocol Version 4 ▸ Properties ▸ Advanced… ▸ desmarque Automatic metric e defina um valor (número baixo = maior prioridade).

Por PowerShell:

# Ver métricas atuais
Get-NetIPInterface -AddressFamily IPv4 | Format-Table InterfaceAlias,AutomaticMetric,InterfaceMetric

Desativar automático e definir métrica (exemplo)

Set-NetIPInterface -InterfaceAlias "Cameras" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 5
Set-NetIPInterface -InterfaceAlias "Clientes" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 15

Após ajustar, confirme a tabela de rotas:

route print

Manter apenas um gateway padrão

Em servidores multihomed, regra de ouro: apenas uma NIC deve ter o gateway padrão. A outra(s) NIC(s) não devem definir gateway — use rotas estáticas para os destinos que exigem aquela interface.

# Exibe rotas 0.0.0.0/0
Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Format-Table -Auto

Remover default gateway da NIC "Cameras" (exemplo)

Remove-NetRoute -InterfaceAlias "Cameras" -DestinationPrefix "0.0.0.0/0" -Confirm:$false

Definir/ajustar gateway padrão apenas na NIC "Clientes"

New-NetRoute -InterfaceAlias "Clientes" -DestinationPrefix "0.0.0.0/0" -NextHop 192.168.10.1 -PolicyStore PersistentStore

Adicionar rotas estáticas específicas

Para forçar que o tráfego de/para as câmaras use a NIC “Cameras”, use rotas persistentes:

# Rota de host (um dispositivo de câmara específico)
route add -p 192.168.10.50 mask 255.255.255.255 0.0.0.0 IF <IFINDEXDACAMERAS>

Rota de rede "on‑link" (toda a rede de câmaras /24) pela NIC "Cameras"

New-NetRoute -DestinationPrefix 192.168.10.0/24 -InterfaceAlias "Cameras" -NextHop 0.0.0.0 -PolicyStore PersistentStore

Conferir o caminho escolhido

Get-NetRoute -DestinationPrefix 192.168.10.0/24 | Format-Table ifIndex,InterfaceAlias,RouteMetric,NextHop

Dica: para descobrir o ifIndex rapidamente: Get-NetIPInterface | Sort-Object ifIndex.

Separar com VLANs/sub‑redes

É a solução mais limpa quando a aplicação exige duas NICs distintas. Planeje endereços e, se possível, roteie no core/firewall.

Fluxo	Sub‑rede	NIC	Gateway	Observações
Câmaras → Servidor	192.168.10.0/24 (VLAN 10)	Cameras (192.168.10.10)	Sem gateway	Apenas tráfego local/L2; rotas on‑link.
Servidor → Clientes/NVR	192.168.20.0/24 (VLAN 20)	Clientes (192.168.20.10)	192.168.20.1	Único gateway padrão do host.

NIC Teaming e quando usar

Se o objetivo não é separar fluxos, e sim redundância e/ou mais banda, considere NIC Teaming (LBFO) no Windows Server 2019. O teaming apresenta um único adaptador lógico ao sistema e à aplicação, evitando assimetrias. Tipos comuns:

Switch‑Independent (ativo/ativo com balanceamento ou ativo/passivo) — não exige LACP no switch.
LACP (802.3ad) — exige configuração no switch, facilita agregação de banda.

Para ambientes com Hyper‑V, o Switch Embedded Teaming (SET) é a alternativa moderna quando o tráfego é majoritariamente virtualizado.

DNS, registro e descoberta

Evite que a NIC dedicada às câmaras “polua” o DNS corporativo com um IP que os clientes não devem usar. Nas propriedades TCP/IP da NIC de câmaras, desmarque “Register this connection’s addresses in DNS” ou, via PowerShell:

Set-DnsClient -InterfaceAlias "Cameras" -RegisterThisConnectionsAddress $false

Perfis de Firewall e políticas

Se a NIC “Cameras” aparecer como Public, regras mais restritivas podem bloquear UDP/TCP do software de CCTV. Ajuste para Private (ou DomainAuthenticated):

Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceAlias "Cameras" -NetworkCategory Private

Opção avançada: weak host

Em topologias muito específicas, pode ser necessário permitir que uma NIC aceite/encaminhe tráfego cujo destino por rota pertença à outra interface (weak host). Use com parcimónia e somente se entender o impacto:

netsh interface ipv4 show interface
netsh interface ipv4 set interface name="Cameras" weakhostreceive=enabled
netsh interface ipv4 set interface name="Cameras" weakhostsend=enabled

Na maioria dos cenários, basta métricas, rotas e o princípio de “um único gateway padrão”.

Exemplos práticos

Cenário A — manter ambas as NICs no mesmo /24

Objetivo: NIC “Cameras” (192.168.10.10) só recebe streams; NIC “Clientes” (192.168.10.20) só atende/entrega a clientes/NVR.

Defina métricas: Cameras = 5, Clientes = 15.
Deixe apenas “Clientes” com gateway padrão.
Crie rotas de host para cada câmara pela NIC “Cameras”:
route add -p 192.168.10.50 mask 255.255.255.255 0.0.0.0 IF <IFINDEX_Cameras>
Valide com ping -S 192.168.10.10 192.168.10.50 e netstat.

Cenário B — separar por VLANs

Objetivo: isolar difusão e segmentar segurança.

Crie VLAN 10 (câmaras) e VLAN 20 (clientes) no switch.
NIC “Cameras” em VLAN 10 com IP 192.168.10.10/24 (sem gateway).
NIC “Clientes” em VLAN 20 com IP 192.168.20.10/24 (gateway 192.168.20.1).
Adicione, se necessário, rotas no core/firewall permitindo o tráfego entre as redes segundo a política.

Erros comuns que sabotam a separação de fluxos

Configurar dois gateways padrão no mesmo servidor.
Deixar Automatic Metric ativo em ambas as interfaces e confiar na “ordem” da lista.
Permitir que a NIC de câmaras registre no DNS, fazendo clientes resolverem o IP “errado”.
Esquecer de atualizar a vinculação da aplicação para o IP/NIC novo após a migração.
Drivers desatualizados/“offloads” agressivos (LSO/RSC) causando PPS baixo ou perda.

Scripts prontos para usar

Substitua "Cameras" e "Clientes" pelos nomes/aliases reais das suas interfaces.

# 1) Métricas e gateway
Set-NetIPInterface -InterfaceAlias "Cameras" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 5
Set-NetIPInterface -InterfaceAlias "Clientes" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 15

Remover default da NIC de câmaras (se existir)

$def = Get-NetRoute -InterfaceAlias "Cameras" -DestinationPrefix "0.0.0.0/0" -ErrorAction SilentlyContinue
if ($def) { $def | Remove-NetRoute -Confirm:$false }

Definir default apenas na NIC "Clientes"

New-NetRoute -InterfaceAlias "Clientes" -DestinationPrefix "0.0.0.0/0" -NextHop 192.168.10.1 -PolicyStore PersistentStore

2) Rotas on‑link de câmaras (exemplos)

$camIf = (Get-NetIPInterface -InterfaceAlias "Cameras" -AddressFamily IPv4).InterfaceIndex
route add -p 192.168.10.50 mask 255.255.255.255 0.0.0.0 IF $camIf
route add -p 192.168.10.51 mask 255.255.255.255 0.0.0.0 IF $camIf

3) DNS: evitar registro pela NIC de câmaras

Set-DnsClient -InterfaceAlias "Cameras" -RegisterThisConnectionsAddress $false

4) Perfil de firewall

Set-NetConnectionProfile -InterfaceAlias "Cameras" -NetworkCategory Private

5) Verificações finais

route print
Test-NetConnection -ComputerName 192.168.10.50 -SourceAddress (Get-NetIPAddress -InterfaceAlias "Cameras" -AddressFamily IPv4).IPAddress

Monitoramento e validação contínua

Contadores do Windows: monitorize \Network Interface(*)\Bytes Received/sec e Bytes Sent/sec para confirmar que cada fluxo usa a NIC esperada.
Captura de pacotes (Event Tracing for Windows ou Wireshark) limitada às portas da aplicação, filtrando por ip.src/ip.dst.
Logs do software de CCTV: verifique IP local de escuta/saída pós‑mudança.

Perguntas frequentes

Posso manter duas NICs no mesmo /24? Pode, mas não é o ideal. Se mantiver, defina métricas distintas, apenas um gateway padrão e rotas estáticas para forçar caminhos.

Por que funcionava no Server 2012 R2 e agora não? Diferenças de métrica automática, ajustes de rede e drivers podem ter mudado o custo efetivo das rotas. No 2019, a pilha de rede está mais rigorosa em seguir a melhor rota — explicite métricas/rotas para obter o mesmo comportamento.

NIC Teaming resolve? Sim se a meta for alta disponibilidade/banda e um único IP; não se a meta for separar fluxos por IP/NIC.

Devo habilitar “weak host”? Só em casos muito específicos. Prefira rotas e métrica correta.

Preciso de dois gateways? Não. Use um gateway padrão e rotas estáticas para os destinos da outra NIC.

Resumo prático

Defina métricas manuais (desative Automatic Metric).
Mantenha apenas um gateway padrão no servidor.
Use rotas estáticas para amarrar redes/hosts à NIC correta.
Se possível, separe por VLANs para isolar tráfego de câmaras e clientes.
Atualize drivers e valide a vinculação na aplicação.

Em suma: não é uma falha do Windows Server 2019, mas o resultado esperado da seleção de rotas quando duas interfaces coexistem na mesma sub‑rede. Com métricas, rotas bem definidas ou segmentação por VLAN, a maioria dos cenários de CCTV volta a funcionar exatamente como planejado.