Vous avez migré votre serveur de vidéosurveillance de Windows Server 2012 R2 vers 2019 ; deux cartes réseau (NIC) partagent désormais le même VLAN, mais seule l’une d’elles véhicule le trafic. Cette page détaille toutes les causes, commandes PowerShell et bonnes pratiques pour rétablir une distribution propre des flux « caméras » et « clients/stockage ».
Problématique
Un serveur d’enregistrement CCTV dispose de deux interfaces :
- NIC 1 (CAM) – doit absorber les flux UDP/TCP entrants des caméras.
- NIC 2 (CLIENTS) – doit servir les flux décodés aux postes de garde et pousser les archives sur le NAS.
Après mise à niveau vers Windows Server 2019, l’ensemble du trafic transite par une seule carte ; l’autre reste pratiquement à zéro octet. Le double adressage dans le même /24 — sans agrégation — sème le doute dans l’algorithme Windows de sélection d’interface.
Architecture initiale et symptômes observés
- Deux ports RJ‑45 1 Gb/s reliés au même switch manageable.
- Adresses IP : 192.168.10.100 (CAM) et 192.168.10.101 (CLIENTS) /24.
- Une seule passerelle par défaut (192.168.10.1).
- Dans
Get-NetAdapterStatisticsla colonne BytesTotal reste nulle sur la NIC « CLIENTS ». - Le logiciel NVR propose un sélecteur d’interface mais l’ID GUID a changé après la migration.
Causes les plus fréquentes
| Cause | Explication |
|---|---|
| Ordre de liaison / métrique automatique | Windows compare la InterfaceMetric. Deux valeurs identiques=trafic unique. |
| Routes ambiguës | Entrées 0.0.0.0/0 ou 192.168.10.0/24 doublonnées redirigent vers un seul NextHop. |
| Conception réseau non recommandée | Deux IP dans le même VLAN sans teaming provoquent une concurrence directe. |
| Pilotes ou firmware obsolètes | Anciennes versions désactivent RSS/VMQ, cassant la distribution. |
Fonctionnement interne de la sélection d’interface sous Windows Server 2019
Depuis Windows Vista, la pile TCP/IP choisit la route la plus spécifique (Longest Prefix Match) puis la valeur la plus basse de la colonne Metric (addition de la métrique d’interface et de la métrique de route). Lorsque deux cartes partagent un masque /24 avec la même passerelle, les deux routes 0.0.0.0/0 sont strictement identiques. Sans intervention, AutomaticMetric calcule un score similaire ; la première carte découverte lors du démarrage gagne, d’où l’apparente panne de la seconde.
À cela s’ajoutent :
- RSS / Receive Side Scaling – répartit les interruptions, mais ne répartit pas les flux entre deux NIC externes.
- NDIS 6.x – attribue un #Index unique à chaque NIC ; certains pilotes multiplient les chemins DMA, ce qui peut perturber la détection du logiciel CCTV après mise à jour majeure.
Pistes de résolution pas à pas
| Étape | Commandes / GUI | Résultat recherché |
|---|---|---|
| 1. Fixer l’ordre de liaison | Exécutez ncpa.cpl → Paramètres avancés | La NIC « CAM » apparaît avant « CLIENTS ». |
| 2. Forcer les métriques | Set-NetIPInterface -InterfaceAlias "CAM" -InterfaceMetric 10 Set-NetIPInterface -InterfaceAlias "CLIENTS" -InterfaceMetric 20 | Le routage distingue clairement les deux chemins. |
| 3. Nettoyer la table de route | route print ou Get-NetRoute | Aucune route dupliquée, suppression des entrées fantômes. |
| 4. Mettre à jour le pilote | Site constructeur + Windows Update | Compatibilité NDIS 6.8, RSS conforme. |
| 5. Activer le NIC Teaming (optionnel) | Gestionnaire de serveur → NIC Teaming | Switch‑Independent / Dynamic : répartition/haute dispo. |
| 6. Lier l’IP dans l’application CCTV | Panneau de config du NVR | Le logiciel n’utilise que l’interface GUID spécifiée. |
Script : configuration rapide en PowerShell
# Variables
$cam = "Ethernet 1"
$cli = "Ethernet 2"
# Ordre de liaison
Set-NetIPInterface -InterfaceAlias $cam -InterfaceMetric 10 -AutomaticMetric Disabled
Set-NetIPInterface -InterfaceAlias $cli -InterfaceMetric 20 -AutomaticMetric Disabled
# Routes dédiées
New-NetRoute -DestinationPrefix 239.0.0.0/8 -InterfaceAlias $cam -NextHop 0.0.0.0 -RouteMetric 10
New-NetRoute -DestinationPrefix 192.168.10.0/24 -InterfaceAlias $cam -NextHop 0.0.0.0 -RouteMetric 10
# Vérification
Get-NetRoute -AddressFamily IPv4 | Sort-Object ifMetric,RouteMetricExemple complet : passer à deux VLAN distincts
Pour éliminer toute ambigüité, on isole physiquement les flux :
| VLAN | Rôle | Plage IP | Passerelle |
|---|---|---|---|
| 10 | Caméras | 192.168.10.0/24 | — |
| 20 | Clients & NAS | 192.168.20.0/24 | 192.168.20.1 |
On configure alors :
# CAM sur VLAN 10
New-NetIPAddress -InterfaceAlias $cam -IPAddress 192.168.10.100 -PrefixLength 24
# CLIENTS sur VLAN 20
New-NetIPAddress -InterfaceAlias $cli -IPAddress 192.168.20.100 -PrefixLength 24 -DefaultGateway 192.168.20.1
# Routes unicast caméra → NAS via CLIENTS
New-NetRoute -DestinationPrefix 192.168.20.0/24 -InterfaceAlias $cli -NextHop 192.168.20.1Le logiciel NVR reçoit toujours les vidéos sur CAM grâce à des flux unicast/multicast internes, tandis que le NAS reste joignable via CLIENTS. Les tests iperf montrent un débit cumulé proche de 2 Gb/s.
Surveillance et validation en production
perfmon.exe→ Network Interface\Bytes Total/sec : ajoutez les deux interfaces sur le même graphique.Get-NetAdapterRsspour vérifier que RSS est Enabled.- Wireshark : filtre
ip.addr==192.168.10.100puisip.addr==192.168.20.100et confirmez la séparation des flux. - Event Viewer → Microsoft‑Windows‑NetworkProfile : surveillez les bascules de profil (Privé/Domaine) qui forcent parfois la redétection DHCP.
Alternative : NIC Teaming en mode Switch‑Independent
Si l’objectif principal est la défaillance zéro plutôt qu’un routage différencié, NIC Teaming réunit les deux ports dans une équipe virtuelle unique. Windows distribue alors les sessions TCP à l’aide de l’algorithme Dynamic (hash de flux + pile RSS). La configuration d’un NVR y est souvent transparente ; en revanche :
- Les flux multicast des caméras requièrent l’option Enable RSS Load Balancing.
- Le switch n’a pas besoin de LACP (mode indépendant).
- Le débit maximal reste plafonné à 1 Gb/s par flux lorsqu’il n’y a pas de clients multiples.
Bonnes pratiques complémentaires
- Désactiver Auto‑Metric sur toutes les interfaces non routées.
- Verrouiller la vitesse & duplex à 1 Gb/s Full pour éviter l’autonégociation asymétrique.
- Réserver les adresses DHCP statiquement afin que les caméras sachent toujours où envoyer.
- Sécuriser le pare‑feu :
- Profil Privé → ports RTSP/554, HTTP/80, HTTPS/443, ONVIF/3702.
- Limiter CLIENTS au seul sous‑réseau de visualisation.
- Sauvegarder le fichier
netsh advfirewall exportavant toute modification « test ».
Foire aux questions
Pourquoi ne pas simplement ajouter une seconde passerelle ?
Deux passerelles par défaut créent deux routes 0.0.0.0/0 équivalentes. Windows ne pratique pas de routage multichemin sur IPv4 sans protocole supplémentaire ; la première route (plus faible métrique) gagne toujours.
Peut‑on utiliser Receive Side Coalescing pour équilibrer ?
Non. RSC consolide les segments TCP sur une NIC, il n’équilibre pas la charge entre deux NIC physiques.
Le Teaming ajoutera‑t‑il de la latence ?
En mode Switch‑Independent, la latence ajoutée est négligeable (<5 µs) car l’équipe fonctionne dans le pilote NDIS. Elle reste inférieure au délai de 33 ms entre deux images vidéo 30 fps.
Comment s’assurer que l’application CCTV choisira toujours la bonne carte ?
Ouvrez le fichier de configuration (XML/INI) ou la base de registre du logiciel NVR ; la plupart référencent le GUID de l’interface (visible dans Get-NetAdapter). Remplacez l’ancien GUID post‑migration.
Conclusion
Avec deux cartes réseau dans un même sous‑réseau, Windows Server 2019 préfère la carte à la métrique la plus basse, laissant la seconde inutilisée. En fixant l’ordre de liaison, en forçant les métriques et, idéalement, en séparant les VLAN, vous contrôlez de manière fiable quel flux emprunte quelle interface. Pour une redondance pure, envisagez plutôt le NIC Teaming. Testez chaque modification avec ping -S, iperf et Wireshark avant de basculer votre parc de caméras en production ; vous éviterez ainsi les pertes de trames, la pixelisation et les alarmes fantômes.