Discussion :

[boboss123]

Bonjour,

Je connais le protocole RSTP pour gérer des anneaux. Ce protocole peut aussi gérer des réseau maillés.
=> il me semble avoir entendu parler qu'il existait un autre protocole (non propriétaire) qui ne gérait que les anneaux (pas de réseau de type maillé) mais qui était plus efficace : je ne me rappelle plus le nom. Vous connaissez le nom ? Il vaut mieux l'utiliser à la place de RSTP sur les boucles non ?

Merci d'avance

[Invité]

Salut,

tu dois sans doute parler de EAPS, normalisé par la RFC3619 (développé par Extreme Networks).

Steph

[boboss123]

oki merci

A priori, le (R/M)STP à l'air plus répandu que l'EAPS : il y a une raison à cela ?
=> lorsque tu parts sur un réseau de type anneau, tu utilises quel protocole (et pourquoi ? ) ?

[Invité]

A priori, le (R/M)STP à l'air plus répandu que l'EAPS : il y a une raison à cela ?

Oui, ils sont plus répandus parce qu'ils émanent d'un effort commun entre plusieurs constructeurs, ce qui a donné naissance aux protocoles de la famille 802.1d qui ont été standardisés par l'IEEE.

EAPS quant à lui, est à l'origine un protocole propriétaire développé par Extreme Networks, puis porté sur d'autres plateformes. EAPS a par la suite été standardisé sous la RFC3619.

lorsque tu parts sur un réseau de type anneau, tu utilises quel protocole (et pourquoi ? ) ?

Mon cerveau étant perverti par Cisco depuis longtemps, je suis plutôt orienté 802.1d

J'utilise donc généralement RSTP/MSTP...

A noter que le protocole EAPS n'est pas disponible sur toutes les plateformes, ça n'est donc pas un "réflexe naturel" de l'utiliser. Pour ma part, je ne l'ai déployé qu'une seule fois. De plus, à cette époque, si un réseau EAPS était étendu avec des équipements qui ne supportent pas le protocole, il fallait refaire le design puisque protocoles EAPS et 802.1d étaient incompatibles (je parle à l'imparfait, ça a peut-être changé).

EAPS converge très rapidement en cas de changement de topologie (je crois que c'est de l'ordre de quelques millisecondes) mais c'est justement lié au fait qu'il s'appuie sur un anneau simple : un des noeuds est Master EAPS sur l'anneau et va bloquer une de ses interfaces de la même façon que le Spanning Tree. Si on rajoute un lien physique supplémentaire entre 2 noeuds EAPS non-voisins dans l'anneau, il faut alors reconfigurer la topologie avec 2 anneaux EAPS, etc. Encore une fois, ça a peut-être changé, je n'ai pas manipulé ce protocole depuis très longtemps.

Steph

[boboss123]

oki merci pour les infos

[boboss123]

Rebonjour,

Voici le genre de topologie classique que je rencontre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
                        +-----+   
                        | CAM |
                        +-----+
                           |
                           |
                     +-----------+               +-----------+
                     |  SWITCH   |               |    PC     |
                     +-----------+               +-----------+  
                        /      \                      |         
                      /          \                    |         
                    /              \              --------       
 +-----+    +-----------+     +-----------+     /          \    +------------------+ 
 | CAM |----|  SWITCH   |     |  SWITCH   |----|  réseaux   |---|    Serveur       | 
 +-----+    +-----------+     +-----------+     \          /    | d'enregistrement | 
                    \              /              --------      +------------------+          
                      \          /          
                        \      /          
                     +-----------+   
                     |  SWITCH   |  
                     +-----------+      
                           |            
                           |            
                        +-----+ 
                        | CAM |
                        +-----+

- Chaque caméra envoie un flux unicast vers le serveur d'enregistrement + 1 flux multicast (chaque flux fait environ 4Mb) pour qu'un poste qui se connecte au réseau puisse voir les caméras en directe.
- Les caméras effectuent des patrouilles (on peut les commander a distance) => en général, c'est du PELCO
- Les switchs sont reliés entre eux par des liens Gigabits (ce sont des switch L2 avec gestion de VLAN et RSTP).
- Les caméras sont reliées aux switch via des liens fibre optique 100Mb
- Il y a un flux data qui circule aussi sur le réseau

1- Est-ce que c'est pour vous une bonne architecture réseau ?

2- Je m'occupe de vendre les switchs (ceux indiqué sur le schéma => pas ceux qui sont dans le nuage "réseau") et le problème est qu'en général, le client (qui ne maitrise pas trop le sujet) me demande combien de caméra il peut mettre sur le réseau. Que dois-je leur répondre exactement ? Il suffit des faire 1Gb / ((nb_flux_par_camera x nb_camera x debit_moyen_d_un_flux) x 120%) ?
=> le "x 120%", c'est pour prendre une marge de 20% en cas de piques
=> je ne pense pas que ça soit si simple (voir http://www.developpez.net/forums/d12...rveillance-ip/). Quels sont les paramêtres a prendre en compte ?
=> que puis-je annoncer comme valeur pour être sure de ne pas me planter ?
=> en gros j'aimerais pourvoir les conseiller sur quelques topologies et de leur expliquer brièvement ce qu'ils doivent configurer (quitte à sur-dimensionner un peu ma partie réseau... si leur partie réseau n'est pas correctement dimensionnée, ce n'est pas trop mon problème mais je dois pouvoir quand même garantir que le problème de vient pas de mes switchs )

3- Donc si j'ai bien compris :
- il faut mettre toutes les caméras dans le même VLAN et le flux data dans un autre VLAN
- configurer le VLAN des caméra avec un niveau de priorité haute
- utiliser le champs DSCP pour que le flux de contrôle de caméra soit moins prioritaire que celui des flux vidéos
=> c'est bien ça qu'il faut faire ?

[Invité]

Globalement, la topologie semble correcte et tu as des données tangibles pour dimensionner les liens et les équipements.
Concernant la bande passante requise par les cameras IP, ce sont des données constructeurs. Ils sont normalement en mesure de fournir des abaques en fonction du codec, du rafraîchissement (fps) et de la définition.

Il suffit des faire 1Gb / ((nb_flux_par_camera x nb_camera x debit_moyen_d_un_flux) x 120%) ?

Non, parce qu'il y a aussi du flux data qui circule sur les liens inter-switches !

D'autre part, je vois un réseau de transit... Il faudrait calculer le dimensionnement relativement au lien de plus bas débit qui se trouve le long du chemin entre les switches et le serveur qui collecte les flux videos y compris la vitesse d'accès Ethernet du serveur. Parce que c'est un point très souvent oublié... On monte un backbone avec des aggrégats EtherChannel/LACP de plusieurs Gb/s et la station collectrice est en 100 Mb/s

Enfin, si le réseau de transit était l'Internet, oublie ta solution

Ceci dit, si tu n'as aucune visibilité sur la volumétrie du flux data, il va falloir émettre des hypothèses (ça, généralement, les clients le comprennent). Par exemple, tu peux partir sur une distribution 50/50 de la plus petite bande passante disponible pour calculer le nombre de cameras. Il faut bien insister auprès du client qu'il devra faire un minimum de métrologie quand le réseau est opérationnel...

il faut mettre toutes les caméras dans le même VLAN et le flux data dans un autre VLAN

Oui, segmentes bien les flux en 2 VLANs. Ca permettra en plus d'équilibrer la charge sur les liens du switch connecté au réseau de transit (le placer comme Root Bridge des 2 instances et jouer sur le cost Spanning Tree des 2 interfaces).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
                        +-----+   
                        | CAM |
                        +-----+
                           |
                           |
                     +-----------+
                     |  SWITCH   |
                     +-----------+ 
                     /           \  Port blocking        
                    /             X
                   /               \ VLAN Cameras     
 +-----+    +-----------+     +-----------+
 | CAM |----|  SWITCH   |     |  SWITCH   |----> 
 +-----+    +-----------+     +-----------+
                   \               /Port blocking       
                    \             X          
                     \           /   VLAN Data
                     +-----------+   
                     |  SWITCH   |  
                     +-----------+      
                           |            
                           |            
                        +-----+ 
                        | CAM |
                        +-----+

- configurer le VLAN des caméra avec un niveau de priorité haute
- utiliser le champs DSCP pour que le flux de contrôle de caméra soit moins prioritaire que celui des flux vidéos

Sur des équipements L2, on utilise le champ COS Ethernet. Ensuite, on configure les équipements L3 sur le transit des paquets en utilisant une matrice de correspondance COS/DSCP pour faire un rewrite de l'en-tête IP...
Quant à dissocier le flux de contrôle des cameras des flux videos, surtout pas, ça va engendrer des désynchronisations.

Steph

[boboss123]

Oki merci pour les infos

D'autre part, je vois un réseau de transit... Il faudrait calculer le dimensionnement relativement au lien de plus bas débit qui se trouve le long du chemin entre les switches et le serveur qui collecte les flux videos y compris la vitesse d'accès Ethernet du serveur.

Ok, mais à la limite ce n'est pas trop mon problème s'ils ont mal dimensionné leur réseau. Par contre là où c'est mon problème, c'est que s'il y a un dysfonctionnement sur le réseau, if faut arriver à prouver que le problème ne vient pas de mon matériel... et là, je ne vois pas trop comment faire (ex: si le serveur enregistre des sauts d'images) ...

[Invité]

Ok, mais à la limite ce n'est pas trop mon problème s'ils ont mal dimensionné leur réseau.

Ok, mais je pense qu'il est important d'évoquer ce point tout de même...

Par contre là où c'est mon problème, c'est que s'il y a un dysfonctionnement sur le réseau, if faut arriver à prouver que le problème ne vient pas de mon matériel... et là, je ne vois pas trop comment faire (ex: si le serveur enregistre des sauts d'images) ...

Oui, là, c'est parti pour le troubleshooting

C'est le challenge des applications temps réel/multimedia qui requièrent de la QoS : la QoS doit être assurée de bout-en-bout mais c'est une vision macroscopique parce qu'elle s'appuie sur du PHB (Per-Hop-Behavior). Tous les équipements L2/L3 intermédiaires entre ton "switch de frontière" et le serveur de collecte des flux videos devront être capables de réagir à la moindre congestion en fonction des champs COS/DSCP. S'il subsiste un "maillon faible" dans la chaîne, ça peut rapidement virer à la catastrophe...

Quels sont tes plans en terme de recette de ce type de réseau ?

Steph

[boboss123]

Ok, mais je pense qu'il est important d'évoquer ce point tout de même...

Tout a fait... le but étant quand même que tout le monde soit content (que le client ait une installation qui fonctionne et que moi que je passe le minimum de temps sur la partie support).

Quels sont tes plans en terme de recette de ce type de réseau ?

Et bien le problème, c'est qu'il n'y en a généralement pas : le client commande ce qu'il y a au catalogue en nous demandant juste si ça va marcher et ce qu'il faut activer comme fonctions. Ce sont des marchés de petite taille avec des marges assez faible : donc je ne me vois pas rédiger un cahier des charges pour chaque affaire...
=> ensuite, il me contacte s'il n'arrive pas à configurer mes produits correctement : c'est cette partie que j'aimerais bien supprimer en redirigeant de la doc décrivant quels sont les points à contrôler et comment identifier la source d'un problème (pour éviter que je perde du temps à résoudre un problème qui vient de leur part).
=> Quand un client ajoute des produits sur un réseau existant qui fonctionne, si ça ne marche pas, tout de suite il pense que le problème vient du nouveau matériel...alors qu'en générale, ça vient du réseau existant qui est mal configuré... et là, c'est à moi de lui prouver qu'il a tord

=> vendre un switch en indiquant seulement les débits des liens et les fonctionnalités, ce n'est peu être pas assez ? est-ce qu'il y a aurait un intérêt à faire des tests poussés sur mes switch ? si oui, que dois-je faire comme tests (il y a tellement de configurations/matériel possible que c'est impossible de tout tester... par exemple avec un codec vidéo donné, je pense que selon le modèle de la caméra et du serveur ça peut marché ou ne pas marché, non ?) ) ?

En gros, si le client me demande si ça va marcher avec n caméra de tel marque, tu lui répondrais quoi (réponse générique possible ?) ?

[Invité]

est-ce qu'il y a aurait un intérêt à faire des tests poussés sur mes switch ? si oui, que dois-je faire comme tests (il y a tellement de configurations/matériel possible que c'est impossible de tout tester... par exemple avec un codec vidéo donné, je pense que selon le modèle de la caméra et du serveur ça peut marché ou ne pas marché, non ?) ) ?

Indépendamment du type de camera utilisé, si j'étais ton client, je voudrais que tu me prouves que les flux videos et les flux data en sortie du switch de frontière sont émis avec le champ COS qui va bien et que tu me dises quelle commande utiliser pour le modifier le cas échéant.

Parce que comme expliqué précédemment, lorsque ces flux vont traverser un équipement L3 dans le réseau de transit jusqu'au serveur de collecte, il va falloir configurer une matrice de correspondance entre les champs COS et DSCP. A moins que tout soit en L2 jusqu'au serveur et dans ce cas, le client doit vérifier que tous les équipements de la chaîne de liaison utilisent les mêmes valeurs de COS pour injecter le traffic video dans les priority queues.

En gros, si le client me demande si ça va marcher avec n caméra de tel marque, tu lui répondrais quoi (réponse générique possible ?) ?

Là, je ne m'embêterais pas... Tu donnes ta formule :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
K = ENT [ V / (n * d * 1.2)]

K nombre de cameras
n nombre de flux par camera
d débit moyen par flux en Mb/s
V débit voulu pour la video en Mb/s

C'est de la responsabilité du client :
- de se rapprocher de son fournisseur de cameras IP pour obtenir les débits requis
- d'évaluer la bande passante qu'il veut dédier pour la video (en étant certain qu'il restera de la bande passante pour les flux data).

Steph

[boboss123]

Oki, oki
merci encore

[Andnotor]

Je ne suis pas un pro du réseau, loin de là, mais je m'étonne que l'enregistreur ne soit pas sur le VLAN des caméras et qu'il n'y ait pas simplement un système pour centraliser des flux basse-résolution/framerate (suffisant à la visualisation en direct) côté PC...

[boboss123]

Je ne suis pas un pro du réseau, loin de là, mais je m'étonne que l'enregistreur ne soit pas sur le VLAN des caméras et qu'il n'y ait pas simplement un système pour centraliser des flux basse-résolution/framerate (suffisant à la visualisation en direct) côté PC...

Il ne me semble pas avoir dis que le serveur n’était pas dans le VLAN des caméra : d'ailleur avec des switch L2, on est obligé que le serveur soit dans le même VLAN.
Après pour l'architecture, je ne suis pas un spécialiste donc c'est pourquoi je demandais conseille : ce que j'ai mis en exemple, c'est une architecture de ce que j'ai déjà vu (peut-être que les personnes qui avaient mis ça en place ont mal organisé leur réseau...d'ailleur, les data étaient dans le même VLAN que la vidéo).
En gros le fonctionnement : les flux unicast pour l'enregistreur et le flux multicast pour les postes de visualisation (remarque : en général, il n'y a qu'un seul poste de visualisation, donc je ne suis même pas sure qu'il y ait un interet de faire transiter des flux multicast...).
=> Le poste de visualisation, c'est un écran géant avec un gugus qui surveille en directe toutes les caméras.