Due schede di rete nella stessa subnet su Windows Server 2019 possono causare traffico “sbilanciato”: una NIC lavora, l’altra resta silente. Questa guida pratica spiega il perché, come verificare l’instradamento e quali impostazioni applicare per ripristinare l’architettura tipica di un sistema CCTV con NIC di “ingresso” e NIC di “uscita”.
Scenario e sintomi
In molte installazioni di videosorveglianza l’applicazione è configurata per ricevere gli stream dalle telecamere su un’interfaccia dedicata e per servire i client e scrivere verso lo storage su un’altra interfaccia. Con l’upgrade da Windows Server 2012 R2 a Windows Server 2019, quando entrambe le NIC sono collegate allo stesso switch ed entrambe hanno indirizzi IP nella medesima subnet (es. 192.168.50.0/24
), ci si può trovare davanti a uno di questi sintomi:
- Solo una NIC trasmette e riceve; l’altra resta pressoché inattiva.
- Le risposte a richieste in arrivo su una NIC escono dall’altra interfaccia.
- I client non raggiungono il servizio se forzati a un IP specifico dell’host.
- Prestazioni variabili, con spike di latenza e perdita di frame degli stream.
Perché succede su Windows Server 2019
Non è un bug. È una conseguenza della coesistenza di due interfacce nella stessa rete logica. Windows costruisce la tabella di routing unendo:
- Route “on‑link” per le reti direttamente connesse (la tua /24);
- Default route (0.0.0.0/0) e rotte statiche o apprese;
- Metrica di interfaccia e di rotta (più bassa → più preferita);
- Ordine di binding e preferenze di alcune API/stack.
In Server 2019 la metrica automatica è più “reattiva”: il sistema ricalcola con maggiore frequenza e precisione quale scheda sia “più conveniente” per inoltrare, e se due NIC sono identiche e nella stessa /24 tenderà a dirottare gran parte del traffico su una sola. Risultato: l’idea “NIC A per ingresso, NIC B per uscita” smette di realizzarsi da sola.
Checklist rapida
Se vuoi solo una check veloce prima di passare ai dettagli:
- Lascia un solo default gateway (di norma sulla NIC “uscita”).
- Imposta metriche diverse per le due NIC o abilita AutoMetric solo sulla prioritaria.
- Sistema l’ordine di binding mettendo la NIC “ingresso” in alto.
- Verifica la tabella di routing con
route print
oGet‑NetRoute
. - Se necessario, crea rotte statiche “vincolate” a un’interfaccia.
- Controlla la configurazione dell’app CCTV (binding IP/NIC).
- Aggiorna driver e firmware delle schede.
- Valuta VLAN/Subnet distinte o NIC Teaming come soluzioni strutturali.
Soluzioni e verifiche chiave
Area di configurazione | Che cosa controllare / fare | Perché è importante |
---|---|---|
Ordine di binding | Impostare la NIC “ingresso” prima di quella “uscita” in Impostazioni avanzate adattatore → Binding Order. | Windows sceglie l’interfaccia preferita anche in base a quest’ordine; un ordinamento errato concentra il traffico su un solo adattatore. |
Metriche | Assegnare manualmente metriche diverse (es. 5 e 10) a ciascuna scheda oppure lasciare “automatic metric” solo a quella prioritaria. | In presenza di due gateway/route identiche, la metrica (più bassa → maggiore priorità) decide quale NIC instrada il traffico. |
Tabella di routing | route print o Get‑NetRoute per verificare che esistano due route distinte per la stessa subnet con metriche diverse.Se necessario, aggiungere rotte statiche vincolando destinazioni specifiche (telecamere ↔ client) a una delle interfacce con -InterfaceIndex . | Conferma che Windows stia davvero differenziando i percorsi e non stia ignorando una delle NIC. |
NIC Teaming (opzionale) | Se l’hardware lo supporta, creare un team in modalità Switch Independent / Dynamic e lasciare all’app CCTV la selezione del singolo IP. | Fornisce bilanciamento e fail‑over senza dover gestire due sottoreti distinte, ma richiede test di compatibilità con il software CCTV. |
Driver e firmware | Aggiornare driver, firmware e, se disponibile, tool di gestione (ad es. Intel PROSet, Broadcom BASP). | Driver obsoleti possono inibire funzionalità avanzate su Server 2019. |
Configurazione dell’app CCTV | Verificare che l’applicazione sia ancora puntata all’IP corretto dopo il cambio di OS; alcuni software rilevano l’IF tramite GUID che cambia con l’upgrade. | Evita che il traffico destinato alla NIC “non attiva” venga in realtà inviato sulla stessa interfaccia funzionante. |
Procedura passo‑passo consigliata
Normalizzare i gateway
Con due NIC nella stessa subnet, evita due default gateway. Regola pratica: gateway solo sulla NIC “uscita”; sulla NIC “ingresso” nessun gateway (verranno usate rotte on‑link e host‑route).
# Rimuovi eventuale default route dalla NIC "INGRESSO"
Get-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceAlias "INGRESSO" | Remove-NetRoute -Confirm:$false
Assicurati che la default route sia presente sulla NIC "USCITA"
$gw = "192.168.50.1" # esempio
New-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceAlias "USCITA" -NextHop $gw -RouteMetric 10 -PolicyStore PersistentStore
Impostare metriche stabili
Disabilita la metrica automatica e assegna valori espliciti e diversi.
# Metrica più bassa = più prioritaria
Set-NetIPInterface -InterfaceAlias "INGRESSO" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 5
Set-NetIPInterface -InterfaceAlias "USCITA" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10
Verifica
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric |
Format-Table ifIndex,InterfaceAlias,InterfaceMetric,AutomaticMetric
Verificare e correggere la tabella di routing
Controlla come Windows vede le rotte locali e la preferenza tra le due NIC.
# Vista "umana" della routing table
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric |
Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric, PolicyStore
Alternativa "storica"
route print
Forzare destinazioni critiche su una specifica NIC
Se telecamere e client condividono la medesima /24, puoi “ancorare” host o blocchi di indirizzi a una NIC con rotte host on‑link o prefissi più specifici. Esempi:
# Esempio: vincola la telecamera 192.168.50.101 a "INGRESSO"
$ifIn = (Get-NetAdapter -Name "INGRESSO").ifIndex
New-NetRoute -DestinationPrefix 192.168.50.101/32 -InterfaceIndex $ifIn -NextHop 0.0.0.0 -PolicyStore PersistentStore -RouteMetric 5
Oppure, se le telecamere occupano la metà bassa del /24, crea un /25 puntato alla NIC di ingresso
New-NetRoute -DestinationPrefix 192.168.50.0/25 -InterfaceIndex $ifIn -NextHop 0.0.0.0 -PolicyStore PersistentStore -RouteMetric 5
Le rotte on‑link usano 0.0.0.0
come NextHop
perché la destinazione è direttamente raggiungibile; ciò spinge Windows a emettere ARP dalla specifica interfaccia. In ambienti con decine di telecamere, genera automaticamente le host‑route:
# Crea host-route per una lista di IP (uno per riga in C:\temp\camlist.txt)
$ifIn = (Get-NetAdapter -Name "INGRESSO").ifIndex
Get-Content "C:\temp\camlist.txt" | ForEach-Object {
New-NetRoute -DestinationPrefix "$_/32" -InterfaceIndex $ifIn -NextHop 0.0.0.0 `
-PolicyStore PersistentStore -RouteMetric 5 -ErrorAction SilentlyContinue
}
Sistemare l’ordine di binding
Apri ncpa.cpl → premi Alt per mostrare il menu → Avanzate → Impostazioni avanzate… → nella lista Connessioni sposta in alto la NIC “INGRESSO”. In alcuni scenari questo influenza la preferenza di risoluzione DNS e di binding applicativo, specialmente se le metriche sono simili.
Verifiche sull’applicazione CCTV
- Controlla che l’app sia ancora associata all’IP corretto. Alcuni software salvano il GUID della scheda, che cambia dopo l’upgrade.
- Se l’app supporta il binding esplicito, imposta l’IP di ascolto per gli stream e l’IP sorgente per l’uscita verso client/storage.
# Mappa alias, ifIndex e GUID per aggiornare i binding lato applicazione
Get-NetAdapter | Select-Object Name, ifIndex, InterfaceGuid, MacAddress | Format-Table -Auto
Driver, firmware e opzioni avanzate della NIC
Aggiorna driver e firmware delle schede. In caso di comportamenti anomali con molte connessioni simultanee:
- Verifica RSS/RSC/LSO e, se necessario, prova a disabilitarle temporaneamente per diagnosi (
Disable-NetAdapterRsc
,Set-NetAdapterAdvancedProperty
). - Assicurati che le due NIC non ereditino profili firewall diversi: Dominio/Privato/Pubblico. Allinea le regole necessarie per porte e protocolli dell’app CCTV.
Confronto con Server 2012 R2 e come replicarne il comportamento
Su 2012 R2 la metrica automatica tendeva a essere meno aggressiva: due/tre caratteristiche hardware simili non portavano a sbilanciamenti marcati. Per avvicinarti a quel comportamento in 2019:
- Disabilita l’AutoMetric su entrambe le NIC e imposta metriche esplicite e distinte.
- Elimina il gateway dalla NIC “ingresso”.
- Se necessario, usa host‑route per le telecamere per rendere il percorso inequivocabile.
Disegni architetturali alternativi
Subnet o VLAN separate
È la soluzione più pulita. Esempio: 192.168.10.0/24
per le telecamere e 192.168.20.0/24
per i client/storage, oppure stesse reti IP ma VLAN diverse sullo switch con porte access distinte per ciascuna NIC. Vantaggi:
- Tabella di routing non ambigua, niente host‑route manuali.
- Dominio di broadcast separato, meno ARP/MDNS/NetBIOS in overlay sugli stream.
- Controllo QoS più semplice lato switch.
NIC Teaming
Quando il software CCTV non ha bisogno di vedere due IP separati, crea un team (Switch Independent, algoritmo Dynamic): il sistema operativo esporrà una sola interfaccia logica, con bilanciamento e fail‑over. Verifica però che:
- Il fornitore dell’applicativo supporti il teaming sul server.
- Non sia richiesto un IP distinto per ingresso/uscita a livello applicativo.
Due IP su una sola NIC
Se la separazione tra flussi è “logica” e non “fisica”, puoi assegnare due indirizzi alla stessa interfaccia. È utile quando l’app si lega a IP diversi ma non ti serve isolamento fisico. Attenzione: niente ridondanza fisica.
Diagnostica efficace
Contatori e strumenti
- Performance Monitor → Network Interface → Bytes Total/sec per entrambe le NIC: controlla in tempo reale dove passa il traffico.
- PowerShell per statistiche rapide:
Get-NetAdapterStatistics -Name "INGRESSO","USCITA" | Format-Table Name, ReceivedBytes, SentBytes -Auto
Ping e traccia, senza risoluzione DNS per velocità
Test-Connection 192.168.50.101 -Source "192.168.50.10" -Count 3
tracert -d 192.168.50.101
Interpretare route print
Cerca due righe “on‑link” per la stessa 192.168.50.0/24
: la metrica più bassa indica l’interfaccia preferita. Se entrambe hanno metrica uguale, Windows può alternare, con effetti imprevedibili per app che si aspettano coerenza di percorso.
Profili firewall e NLA
Se una NIC è in Pubblico e l’altra in Dominio, le policy possono differire. Allinea i profili o crea regole specifiche per gli IP/porte della tua app.
Weak host vs. strong host (avanzato)
Per impostazione predefinita Windows può accettare un pacchetto destinato a un IP anche da un’altra interfaccia e inviare la risposta da una diversa. Con due NIC nella stessa subnet questo aumenta l’ambiguità. In contesti di sicurezza rigorosi puoi valutare il strong host su una NIC:
# Esempio: irrigidire la NIC "INGRESSO"
netsh interface ipv4 set interface "INGRESSO" weakhostreceive=disabled weakhostsend=disabled
Usa questa opzione solo se sai esattamente come l’applicazione gestisce il binding e la risposta, perché può limitare comportamenti prima “tollerati”.
Esempio completo
Obiettivo: telecamere 192.168.50.100‑199
su NIC INGRESSO (192.168.50.10/24
), client/storage su NIC USCITA (192.168.50.11/24
), stesso switch.
- Gateway: togli il gateway da INGRESSO, mantieni
192.168.50.1
su USCITA. - Metrica: INGRESSO = 5, USCITA = 10.
- Rotte: crea un /26 e host‑route dove serve.
# 1) Gateway
Get-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceAlias "INGRESSO" | Remove-NetRoute -Confirm:$false
New-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceAlias "USCITA" -NextHop 192.168.50.1 -RouteMetric 10 -PolicyStore PersistentStore
2) Metriche
Set-NetIPInterface -InterfaceAlias "INGRESSO" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 5
Set-NetIPInterface -InterfaceAlias "USCITA" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10
3) Rotte: metà bassa della subnet per le telecamere
$ifIn = (Get-NetAdapter -Name "INGRESSO").ifIndex
New-NetRoute -DestinationPrefix 192.168.50.0/26 -InterfaceIndex $ifIn -NextHop 0.0.0.0 -RouteMetric 5 -PolicyStore PersistentStore
4) Aggiungi host-route per telecamere fuori dal /26
"192.168.50.150","192.168.50.151" | ForEach-Object {
New-NetRoute -DestinationPrefix "$_/32" -InterfaceIndex $ifIn -NextHop 0.0.0.0 -RouteMetric 5 -PolicyStore PersistentStore
}
5) Verifica
Get-NetRoute -AddressFamily IPv4 | Where-Object { $.DestinationPrefix -like "192.168.50." -or $*.DestinationPrefix -eq "0.0.0.0/0" } |
Sort-Object DestinationPrefix | Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric
Quando scegliere soluzioni strutturali
- Segmentazione L2/L3: se il numero di telecamere è elevato o variabile, mantenere host‑route è oneroso. Subnet o VLAN dedicate sono più scalabili.
- Ridondanza: se il requisito è l’alta disponibilità, il Teaming evita il single‑point‑of‑failure della NIC “ingresso”.
- Compatibilità applicativa: alcuni VMS legano rigidamente ingressi/uscite a IP diversi; in quel caso privilegia subnet/VLAN distinte anziché il Teaming.
Best practice operative
- Documenta alias, ifIndex, IP e VLAN di ogni NIC. Conserva una runbook con i comandi chiave.
- Automatizza la generazione delle host‑route da un file degli indirizzi delle telecamere.
- Monitora con Performance Monitor e script periodici (
Get‑NetAdapterStatistics
) per intercettare deviazioni. - Non disattivare IPv6 solo per “provare”: può generare effetti collaterali inattesi ai profili di rete e alla NLA.
Domande frequenti
Posso lasciare due default gateway?
È sconsigliato quando le NIC sono nella stessa subnet: il sistema può alternare la route predefinita, provocando asincronie nelle risposte e perdita di sessioni.
È sufficiente l’ordine di binding?
No: su Server 2019 contano soprattutto le metriche. L’ordine aiuta, ma non sostituisce metriche e rotte.
Le host‑route sono davvero necessarie?
Solo se vuoi imporre percorsi distinti all’interno della stessa /24. In alternativa, passa a subnet/VLAN separate.
Il Teaming risolve sempre?
Risolve l’HA e il bilanciamento, non la necessità di due IP distinti se l’app li richiede.
Runbook di emergenza
# 0) Snapshot della situazione
Get-NetAdapter | ft Name,ifIndex,Status,MacAddress -Auto
Get-NetIPConfiguration
Get-NetIPInterface -AddressFamily IPv4 | ft ifIndex,InterfaceAlias,InterfaceMetric,AutomaticMetric
Get-NetRoute -AddressFamily IPv4 | ft DestinationPrefix,NextHop,InterfaceAlias,RouteMetric -Auto
1) Un solo gateway
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | ft *
Rimuovi eventuali duplicati sulla NIC "INGRESSO"
Get-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceAlias "INGRESSO" | Remove-NetRoute -Confirm:$false
2) Metriche esplicite
Set-NetIPInterface -InterfaceAlias "INGRESSO" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 5
Set-NetIPInterface -InterfaceAlias "USCITA" -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10
3) Rotte on-link per telecamere
$ifIn = (Get-NetAdapter -Name "INGRESSO").ifIndex
New-NetRoute -DestinationPrefix 192.168.50.0/25 -InterfaceIndex $ifIn -NextHop 0.0.0.0 -PolicyStore PersistentStore -RouteMetric 5
4) Verifica traffico
Get-NetAdapterStatistics -Name "INGRESSO","USCITA"
Conclusioni
Quando due NIC stanno nella stessa subnet, Windows Server 2019 deve essere aiutato a scegliere in modo deterministico “chi fa cosa”. La ricetta è semplice: un solo default gateway, metriche esplicite, ordine di binding coerente e – se serve – rotte on‑link puntuali per le destinazioni critiche. Se il carico cresce o vuoi eliminare complessità, passa a subnet/VLAN distinte o considera il NIC Teaming. Così l’architettura tipica dei sistemi CCTV – “ingresso” per gli stream, “uscita” per client e storage – torna a comportarsi in modo affidabile e prevedibile.
Suggerimenti aggiuntivi in breve
- Evita due gateway nella stessa subnet: rimuovi il gateway sulla NIC “secondaria” e usa rotte statiche dove necessario.
- Subnet diverse = configurazione più pulita: separa telecamere e client/storage in reti logiche distinte.
- VLAN sullo switch: se non vuoi cambiare gli indirizzi, segmenta con VLAN e assegna ogni NIC alla VLAN corretta.
- Monitoraggio in tempo reale: Performance Monitor o
Get‑NetAdapterStatistics
per verificare il bilanciamento. - Confronto con Server 2012 R2: la logica AutoMetric di 2019 è più aggressiva; per replicare il comportamento precedente usa metriche manuali.
In sintesi: non è un “bug” di Server 2019, ma una conseguenza tecnica di due interfacce nella stessa subnet. Differenzia binding, metriche o – meglio – subnet/VLAN per indicare con certezza a Windows quale NIC usare per quale traffico.