La caméra prend-elle en charge le Multicast pour réduire la charge de bande passante dans les grands environnements LAN ?

J'ai vu des réseaux planter parce que 20 moniteurs tiraient le même flux 4K¹ via unicast. C'est douloureux, coûteux et 100% évitable.

Oui, nos caméras PTZ de qualité industrielle prennent entièrement en charge le Multicast (IGMP v2/v3). Dans un grand LAN où plusieurs clients ont besoin du même flux H.265 en même temps, la caméra n'envoie qu'une seule copie de la vidéo. Les commutateurs réseau répliquent ensuite ce flux unique vers chaque spectateur. Cela réduit votre bande passante dorsale de N × Débit à 1 × Débit, quel que soit le nombre d'écrans qui regardent.

Optimisation de la bande passante multicast des caméras PTZ dans les grands LAN

Ci-dessous, je vais vous présenter les questions les plus fréquentes que me posent les intégrateurs de systèmes et les CTO concernant le déploiement Multicast. Chaque réponse est basée sur une expérience réelle de projet, pas sur une copie-coller de fiche technique. Si vous prévoyez une configuration de surveillance multi-stations, un réseau de surveillance à l'échelle de l'usine ou un projet de campus inter-VLAN, continuez à lire.

Table des matières

Combien de clients simultanés peuvent visualiser un seul flux 4K en utilisant le Multicast sur mon réseau ?

Chaque fois que je cite “spectateurs illimités, même bande passante”, les gens pensent que j'exagère. Je n'exagère pas. Mais il y a un piège que la plupart des fournisseurs ne vous diront pas.

Avec le Multicast activé, le nombre de clients simultanés visualisant un seul flux 4K n'est pas limité par la caméra. Il est limité par votre fabric de commutateur et votre capacité d'IGMP snooping. En pratique, un commutateur géré correctement configuré peut desservir 50, 100, voire 200+ points d'extrémité à partir d'un seul flux de 8 Mbps sans ajouter de charge supplémentaire au port uplink de la caméra.

Clients simultanés Multicast flux 4K commutateur réseau

Pourquoi la caméra n'est plus le goulot d'étranglement

Dans un monodiffusion³ configuration, le CPU et l'interface réseau de la caméra doivent générer une session RTP distincte RTP⁸ pour chaque spectateur. J'ai testé cela sur de nombreuses caméras dans notre laboratoire. La plupart des caméras PTZ commencent à perdre des images après 8 à 10 connexions unicast simultanées. Certains modèles moins chers gèlent à 5. La caméra manque simplement de puissance de traitement.

Avec le Multicast, la caméra crée un flux de groupe IGMP. C'est tout. Un seul flux quitte le port Ethernet de la caméra. Le travail de réplication est entièrement transféré à l'infrastructure réseau.

Là où se trouve la véritable limite

Le plafond réel dépend de trois éléments de votre réseau :

Facteur	Ce qu'il contrôle	Limite typique
Bande passante du backplane du commutateur	Données totales que le commutateur peut déplacer en interne	48–256 Gbps sur les commutateurs d'entreprise
Taille de la table IGMP snooping	Combien de groupes multicast et de membres le commutateur peut suivre	1 000–8 000 entrées sur la série Cisco Catalyst
Vitesse du port d'uplink	Le tuyau entre votre commutateur d'accès et votre commutateur central	1 Gbps ou 10 Gbps

Donc, si votre flux 4K H.265 fonctionne à 8 Mbps et que votre uplink est de 1 Gbps, le calcul est simple. L'uplink peut transporter 125 copies de ce flux. Mais avec le Multicast, il ne transporte qu'une un copie sur cet uplink. Le commutateur d'accès du côté du spectateur effectue la réplication localement.

Un chiffre du monde réel

Dans un récent projet d'usine, l'un de nos partenaires en Europe a connecté 64 postes de travail de surveillance à un seul flux 4K PTZ. Le port uplink de la caméra est resté à un plat de 8 Mbps. L'utilisation du CPU de la caméra est restée en dessous de 30 %. Aucune perte d'images. Aucune pointe de latence. La clé était que chaque commutateur sur le chemin avait l'IGMP snooping activé.

Ce qui se passe sans IGMP snooping

Si vous ignorez l'IGMP snooping, le commutateur traite le flux multicast comme une diffusion. Chaque port de chaque commutateur reçoit les données vidéo. Vos imprimantes, vos téléphones VoIP, vos panneaux de contrôle d'accès — tous reçoivent 8 Mbps de vidéo qu'ils n'ont jamais demandée. J'ai vu cela mettre à genoux un réseau de bureau entier en moins de 10 minutes. La réponse à “combien de clients” est donc vraiment “autant que vos commutateurs peuvent gérer”, mais seulement si vos commutateurs sont correctement configurés.

Le Multicast aidera-t-il à prévenir la congestion du réseau lors de la diffusion vers plusieurs stations de sécurité ?

Je parle chaque semaine à des intégrateurs qui blâment la caméra pour une vidéo saccadée. Neuf fois sur dix, le problème ne vient pas de la caméra. C'est l'architecture du réseau.

Le multidiffusion est la méthode la plus efficace pour prévenir la congestion du réseau lorsque plusieurs postes de sécurité visualisent le même flux de caméra. Au lieu que la caméra envoie des flux en double à chaque poste, elle en envoie un, et le réseau le distribue efficacement. Cela élimine le problème de bande passante multiplicative qui cause la congestion, la perte de paquets et le gel de la vidéo.

Le multidiffusion empêche la congestion du réseau des postes de sécurité

Les calculs de congestion : Unicast vs Multicast

Laissez-moi mettre des chiffres réels là-dessus. Disons que vous avez une salle de contrôle avec 16 moniteurs, et chaque moniteur affiche une caméra différente. Mais 4 de ces moniteurs montrent la même caméra PTZ — peut-être une entrée de portail ou une vue critique du périmètre.

Scénario Unicast :

La caméra envoie 4 flux séparés à 6 Mbps chacun.
Utilisation de la liaison montante de la caméra : 24 Mbps.
Le commutateur principal doit router 4 flux indépendants.
Si 3 autres postes dans un deuxième bâtiment veulent également ce flux, la caméra envoie maintenant 42 Mbps pour une seule vue.

Scénario Multicast :

La caméra envoie 1 flux à 6 Mbps.
Chaque commutateur le long du chemin ne transporte que 6 Mbps pour cette caméra, quel que soit le nombre de points d'extrémité qui s'y abonnent.
Le processeur de la caméra reste inactif. L'uplink reste propre.

Les points de congestion que la plupart des gens manquent

La congestion du réseau ne se produit pas toujours là où vous l'attendez. Voici les trois points de contention les plus courants que je vois dans les grands réseaux LAN de surveillance :

Point de contention	Pourquoi il est congestionné	Comment le Multicast le résout
Port uplink de la caméra	Plusieurs sessions unicast saturent le port 100 Mbps	Un seul flux quitte la caméra
Uplink du switch cœur	Le trafic agrégé de dizaines de caméras submerge le trunk	Le trafic Multicast est répliqué en périphérie, pas au cœur
Lien de pont sans fil	Débit limité (souvent 50–100 Mbps effectifs) partagé par tout le trafic	Une copie traverse le pont ; le switch local réplique

Note spéciale pour les projets hors réseau solaires 4G

David, je sais que bon nombre de vos projets impliquent nos systèmes PTZ solaires 4G déployés dans des zones reculées. Voici la vérité honnête : les réseaux publics 4G/5G standard ne prennent pas en charge le Multicast. Les opérateurs mobiles bloquent le trafic IGMP sur leur infrastructure. Donc, si votre caméra distante envoie de la vidéo via 4G vers un VMS cloud, le Multicast n'aidera pas sur ce segment WAN.

Cependant, si vous mettez en place un réseau de pont sans fil local entre plusieurs mâts sur un chantier — disons un chantier avec 5 mâts de caméras et un bureau de chantier — alors le Multicast devient très utile. Le Pont sans fil⁷ ne transporte qu'une seule copie de chaque flux. Le commutateur du bureau du site le réplique sur l'ordinateur portable du contremaître, le moniteur de l'agent de sécurité et le NVR. Cette configuration peut réduire la charge de votre pont sans fil de 60 à 70 %.

IGMP Snooping : L'exigence non négociable

Je ne saurais trop insister là-dessus. Sans IGMP snooping² activé sur chaque commutateur du chemin, le trafic Multicast inonde chaque port. C'est pire que l'unicast car maintenant chaque appareil sur le VLAN reçoit le flux vidéo. Le résultat est une tempête de diffusion. Je dis toujours à nos partenaires : avant d'activer le Multicast sur la caméra, confirmez que l'IGMP snooping est actif sur vos commutateurs. Vérifiez l'interface de gestion du commutateur. Recherchez l'état de l'IGMP snooping dans les paramètres VLAN. S'il est indiqué “désactivé”, corrigez cela d'abord.

L'implémentation Multicast est-elle compatible avec les commutateurs Cisco ou Juniper de couche 3 standard ?

Je reçois souvent cette question des intégrateurs nord-américains. Ils utilisent Cisco ou Juniper dans chaque rack et ont besoin d'une réponse claire avant de spécifier nos caméras dans une offre.

Nos caméras PTZ utilisent les protocoles standard IGMP v2 et IGMP v3 pour le Multicast. Cela signifie qu'elles sont entièrement compatibles avec tout commutateur géré prenant en charge l'IGMP snooping, y compris Cisco Catalyst, Cisco Nexus, Juniper EX series, HPE Aruba et H3C. Il n'y a pas de protocole propriétaire impliqué. Si votre commutateur parle IGMP, il fonctionne avec notre caméra.

Commutateurs Cisco Juniper couche 3 compatibles Multicast IGMP

Pourquoi les normes comptent plus que les noms de marque

Certains fabricants de caméras utilisent des méthodes de streaming propriétaires qui ne fonctionnent qu'avec leurs propres NVR ou leurs propres logiciels. Cela vous enferme dans un seul écosystème. Nos caméras suivent Profil T ONVIF⁴, qui définit exactement comment le Multicast doit être configuré et découvert. Tout VMS conforme ONVIF — Milestone, Genetec, Blue Iris, Digifort — peut détecter automatiquement l'adresse du groupe Multicast et commencer à recevoir le flux.

Compatibilité des versions IGMP

Il existe deux versions d'IGMP qui sont importantes en pratique :

IGMP v2 : La version la plus déployée. Prend en charge les messages de jointure et de départ de base. Fonctionne sur presque tous les commutateurs gérés fabriqués au cours des 15 dernières années.
IGMP v3 : Ajoute le multicast spécifique à la source (SSM). Cela permet au commutateur de filtrer le trafic non seulement par adresse de groupe, mais aussi par adresse IP source. Utile dans les très grands réseaux où plusieurs caméras peuvent utiliser la même plage d'adresses de groupe.

Nos caméras prennent en charge les deux. La caméra est configurée par défaut sur IGMP v2 pour une compatibilité maximale. Vous pouvez passer à la v3 dans l'interface web si votre réseau l'exige.

Plateformes de commutateurs testées

Je veux être précis ici car les affirmations de compatibilité vagues font perdre du temps à tout le monde. Notre équipe d'ingénierie a testé le streaming Multicast sur les plateformes suivantes :

Plateforme de commutateur	IGMP Snooping	Routage Multicast	Résultat du test
Cisco Catalyst 2960/3560/3850	Pris en charge	Pris en charge (modèles L3)	✅ Compatibilité totale
Cisco Nexus 3000/5000	Pris en charge	Pris en charge	✅ Compatibilité totale
Juniper EX2300/EX3400	Pris en charge	Pris en charge	✅ Compatibilité totale
HPE Aruba 2530/2930	Pris en charge	Pris en charge (2930)	✅ Compatibilité totale
H3C S5130/S5560	Pris en charge	Pris en charge	✅ Compatibilité totale
TP-Link TL-SG3428	Pris en charge	Limité	✅ Fonctionne pour un VLAN unique

Qu'en est-il des commutateurs non gérés ?

Les commutateurs non gérés ne prennent pas en charge l'IGMP snooping. Si vous branchez notre caméra sur un commutateur non géré bon marché et activez le Multicast, le commutateur inondera le flux vers tous les ports. Cela va à l'encontre de l'objectif. Pour tout projet où le Multicast est important, vous avez besoin de commutateurs gérés. Ce n'est pas une limitation de la caméra. C'est une exigence fondamentale du réseau.

Interopérabilité inter-fournisseurs en pratique

Un de nos partenaires au Moyen-Orient gère un réseau mixte : commutateurs centraux Cisco, commutateurs de distribution H3C et commutateurs d'accès TP-Link. Ils ont activé le Multicast sur 24 de nos caméras PTZ. Chaque commutateur a correctement géré les adhésions IGMP. La vidéo a été diffusée sans problème sur plus de 40 postes de travail. Le seul problème qu'ils ont rencontré concernait un commutateur TP-Link qui avait le snooping IGMP désactivé par défaut. Une fois qu'ils l'ont activé, tout a fonctionné. La leçon : vérifiez chaque commutateur sur le chemin, pas seulement le cœur.

Puis-je définir une adresse IP de groupe Multicast et une TTL (Time to Live) uniques pour mon projet inter-VLAN ?

Le multicast inter-VLAN est là où la plupart des projets se compliquent. J'ai aidé des dizaines d'intégrateurs à résoudre ce scénario exact, et la réponse commence par une configuration appropriée côté caméra.

Oui, vous pouvez configurer une adresse IP de groupe Multicast et une valeur TTL personnalisées directement dans l'interface Web de la caméra. L'IP du groupe peut être n'importe quelle adresse valide de classe D entre 224.0.0.0 et 239.255.255.255. Le TTL peut être défini de 1 à 255, contrôlant le nombre de sauts de routeur que le flux peut traverser. Pour les déploiements inter-VLAN, définissez le TTL à au moins 16 pour garantir que le flux traverse vos limites de routage de couche 3.

IP de groupe Multicast TTL configuration inter-VLAN caméra PTZ

Comprendre l'adresse Multicast et pourquoi elle est importante

Une adresse IP de groupe Multicast n'est pas comme une adresse IP ordinaire. Elle n'appartient à aucun appareil unique. C'est un “canal” auquel n'importe quel appareil peut s'abonner. Pensez-y comme à une fréquence radio. La caméra diffuse sur un canal spécifique, et tout client qui s'accorde reçoit le flux.

Nos caméras vous permettent de configurer des adresses et des ports Multicast distincts pour trois types de données :

Flux vidéo : Le flux vidéo principal H.265 ou H.264.
Flux audio : Audio bidirectionnel ou unidirectionnel, si votre projet l'exige.
Flux de métadonnées : Résultats d'analyse IA, tels que les boîtes englobantes de détection humaine, les données de plaque d'immatriculation ou les déclencheurs d'événements de mouvement.

Cette séparation est importante. Certaines plateformes VMS s'abonnent uniquement au groupe Multicast vidéo. D'autres ont besoin du groupe de métadonnées pour afficher les superpositions IA. En attribuant différentes adresses de groupe, vous maintenez le trafic organisé et donnez à votre VMS un contrôle granulaire sur ce qu'il reçoit.

TTL : La clé inter-VLAN

TTL signifie Time to Live. Chaque fois qu'un paquet Multicast traverse une limite de couche 3 (un routeur ou un commutateur de couche 3 effectuant un routage inter-VLAN), le TTL diminue de 1. Lorsqu'il atteint 0, le paquet est abandonné.

TTL = 1 : Le flux reste au sein du sous-réseau local. Il ne traversera aucun routeur. Bon pour les configurations à VLAN unique.
TTL = 16 : Le flux peut traverser jusqu'à 16 sauts de routage. C'est suffisant pour la plupart des réseaux de campus avec plusieurs VLAN.
TTL = 32 : Sûr pour les très grands réseaux d'entreprise avec des topologies de routage complexes.
TTL = 128 ou 255 : Uniquement nécessaire pour le Multicast WAN multi-sites, ce qui est rare dans la surveillance.

Je recommande généralement TTL = 32 comme valeur par défaut sûre pour les projets inter-VLAN. Cela vous donne suffisamment de marge sans créer de fuites de trafic inutiles vers des segments réseau distants.

Multicast Inter-VLAN : Le côté réseau

La définition du TTL sur la caméra n'est que la moitié du travail. Votre réseau doit également être configuré pour router le trafic Multicast entre les VLAN. Cela nécessite :

PIM (Multidiffusion indépendant du protocole)⁵: Doit être activé sur les interfaces de niveau 3 de votre commutateur ou routeur principal. PIM-SM (Sparse Mode) est le choix le plus courant.
Point de Rendez-vous (RP)⁶: Dans PIM-SM, vous devez désigner un routeur comme RP. C'est le point de rencontre où les sources et les récepteurs se trouvent.
IGMP sur chaque interface VLAN : Le commutateur de niveau 3 doit exécuter IGMP sur chaque SVI (Switched Virtual Interface) VLAN où se trouvent des caméras ou des visualiseurs.

Chemin de configuration sur la caméra

La configuration est simple. Connectez-vous à l'interface web de la caméra. Naviguez vers :

Réseau > Paramètres avancés > Multicast

À partir de là, vous pouvez définir :

Adresse IP du groupe de multidiffusion (par exemple, 239.1.1.10)
Port de multidiffusion (par exemple, 8600 pour la vidéo, 8602 pour l'audio, 8604 pour les métadonnées)
Valeur TTL (par exemple, 32)
Activer ou désactiver la multidiffusion par flux (flux principal, sous-flux)

Une fois enregistrée, la caméra commence immédiatement à envoyer des rapports d'appartenance IGMP. Tout commutateur compatible IGMP sur le réseau détectera la nouvelle source de multidiffusion et commencera à acheminer le flux vers les clients abonnés.

Un conseil pratique pour les grands projets

Si vous déployez 50 caméras ou plus, planifiez soigneusement vos adresses de groupe de multidiffusion. Je recommande d'utiliser la plage 239.x.x.x (adresses à portée administrative) et d'attribuer à chaque caméra une adresse IP de groupe unique. Par exemple :

Caméra 01 : 239.1.1.1
Caméra 02 : 239.1.1.2
Caméra 50 : 239.1.1.50

Cela facilite grandement le dépannage. Si un flux spécifique pose problème, vous pouvez filtrer par adresse IP de groupe dans Wireshark et isoler le problème en quelques secondes.

Conclusion

Nos caméras PTZ prennent entièrement en charge la multidiffusion avec IGMP v2/v3, des adresses IP de groupe personnalisées et un TTL réglable. Associez-les à des commutateurs gérés, et votre réseau local étendu restera propre, rapide et évolutif.

1. Détails sur la résolution 4K et ses exigences en bande passante. ︎↩︎ 2. Documentation Cisco sur le snooping IGMP pour contrôler le trafic de multidiffusion au niveau du commutateur. ︎↩︎ 3. Comprendre unicast vs multicast pour le streaming vidéo. ︎↩︎ 4. Profil ONVIF officiel pour les fonctionnalités avancées de PTZ et de multidiffusion. ︎↩︎ 5. En savoir plus sur le protocole de routage PIM pour la multidiffusion sur différents segments réseau. ︎↩︎ 6. Livre blanc Cisco sur le Rendezvous Point dans le routage de multidiffusion PIM-SM. ︎↩︎ 7. Explication du pontage sans fil pour étendre les liaisons réseau. ︎↩︎ 8. Apprenez le RTP pour la transmission audio et vidéo en temps réel. ︎↩︎