Discussion :

[Emmanuel Bezençon]

Bonjour,

Je suis actuellement en projet pour les études et je dois créer un réseau composé de plusieurs sous-réseaux routés actuellement avec OSPF et qui aura la particularité d'être configuré pour le multicasting de flux vidéos.
Pour commencer, je veux configurer le service multicast sur un simple routeur qui a d'un côté (relié à un switch) un serveur multicast avec VLC et de l'autre un client multicast.
Quelles configurations son nécessaire sachant que j'utilise IGMP et PIM en dense-mode?
J'ai déjà réussi à configuré de telle sorte que je voix reconnait les flux grâce au protocole SAP mais je ne peux pas les lire. Je soupçonne un problème de conenction au groupe multicast mais ne suis sûr de rien. Comment régler ce problème.

Merci d'avance pour vos réponses!

Manu

[Invité]

Salut,

Si le routeur est un Cisco, il suffit d'activer l'IP Multicast en commande globale puis configurer 'ip pim sparse-dense' sur chaque interface qui participera au mrouting. Il faut ensuite faire un 'sh ip igmp int' pour vérifier que les interfaces du routeur voient bien le traffic multicast.

Je ne comprends pas ta remarque concernant SAP...

Steph

[Emmanuel Bezençon]

Merci Steph pour ta réponse si rapide.
C'est bien sur un routeur Cisco et j'ai déjà configuré le mode dense et avec cela je reçoit les annonce SAP du serveur mais je n'arrive pas à lire le flux. Je visualise bien la diffusion depuis mon client mais je ne peux pas la lire.
Alors je sais pas si dense ou spare-dense-mode change quelque chose mais je ne crois pas.
Est-ce que le fait d'avoir un seul routeur peut poser problèmes?

Merci d'avance.

[Invité]

Que donnent 'sh ip pim nei' and 'sh ip mroute' ? Tu devrais voir les adjacences PIM et une entrée (*, adresse IP multicast) dans la mrouting table.

Si tout ça est conforme, est-ce que ça ne serait pas un problème applicatif ? Est-ce que tu as testé ton serveur et un client en local sur le même switch pour valider ton appli ? Est-ce que tu as un Sniffer sur ton client ?

Steph

[Emmanuel Bezençon]

Au niveau du "sh ip pim nei", ça me sort rien du tout. Pour le "sh ip mroute", pour mon groupe multicast (*, 239.255.10.1) voilà ce que j'ai:
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:16:48/00:02:40

je n'ai pas le fa0/1 qui est celui sur lequel se trouvent les clients.

Ce n'est pas un problème de client et serveur car j'ai déjà testé en local avec un seul switch sans igmp snooping et je diffuse le flux correctement et je peux le visualiser.

Oui j'ai un sniffer mais j'en retire pas grand chose d'après moi, enfin j'y arrive pas trop.

Merci

[Invité]

Au niveau du "sh ip pim nei", ça me sort rien du tout. Pour le "sh ip mroute", pour mon groupe multicast (*, 239.255.10.1) voilà ce que j'ai:
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:16:48/00:02:40

je n'ai pas le fa0/1 qui est celui sur lequel se trouvent les clients.

Ce n'est pas un problème de client et serveur car j'ai déjà testé en local avec un seul switch sans igmp snooping et je diffuse le flux correctement et je peux le visualiser.

Oui j'ai un sniffer mais j'en retire pas grand chose d'après moi, enfin j'y arrive pas trop.

Merci

Si ta mrouting table n'installe pas de mroute spécifique (x.x.x.x, 239.255.10.1) où x.x.x.x est l'IP d'un client, alors le flux multicast ne sera pas établi.

Tu peux attacher les configs du switch et du routeur si tu veux que je jette un coup d'oeil.

Je suppose que c'est une maquette de tests ? Tu pourrais alors activer

Code :

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

debug ip mrouting 239.255.10.1

et

Code :

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

debug ip igmp 239.255.10.1

puis faire une nouvelle tentative de streaming.

Steph

[Emmanuel Bezençon]

Alors j'ai testé le debug et tout ce que ça me ressort après une general query sur les deux interfaces, c'est:
IGMP (0): Repport has illegal group address 224.0.0.252
IGMP (0): Repport has illegal group address 224.0.0.255

Je ne comprends pas trop ce que ça veut dire!?

Je t'ai mis les fichiers de config et le schéma du réseau pour que tu aies tout pour comprendre.
fa0/1 est du côté clients et fa0/0 coté serveur.

Merci, Manu

[Invité]

Bizarre... Tu devrais quand même avoir quelques messages debug...

J'ose espérer que tu as la connectivité IP entre ton serveur et les clients ? Essaies alors la chose suivante

1) Retires les commandes 'bsr-border' (je ne pense pas que ce soit la cause de ton problème mais autant refaire les tests avec la config la plus simple qui soit, on ne sait jamais).
2) Tu réactives les debugs
3) Puis tu entres la commande 'clear ip mroute *'
4) Tu refais le test de streaming

Quant aux adresses 224 que tu as vues, ça n'est pas un problème. Ce sont les adresses utilisées par mDNS (RFC4795).

Steph

[Emmanuel Bezençon]

Je suis d'accord avec toi, il y a quelque chose de bizard. J'ai également essayer d'inverser les clients et le serveur pour voir si les switchs poseraient problème mais rien du tout.

La connection IP est bonne, je peux ping chaque machine sans problème d'un réseau à un autre.

Je te transfert ce que le debug ressort lorsque je refais le test streaming. A mon avis cela me semble normal étant donné que j'ai le 192.168.1.8 qui est sur le même réseau que le serveur et qui peut lire la vidéo mais le 192.168.2.9 est dans l'autre réseau et ne peut pas lire la vidéo, seulement recevoir l'annonce SAP.

Merci

[Emmanuel Bezençon]

En regardant de plus près le fichier de debug que je viens de te joindre, j'ai remarqué qu'il correspondait tout-à-fait entre le client sur le réseau du serveur et l'autre client sur l'autre réseau.
Il y a juste une chose, c'est à la ligne:
MRT(0): set min mtu for (0.0.0.0, 239.255.10.1) 0->1500 pour le client 192.168.2.9 et
MRT(0): set min mtu for (0.0.0.0, 239.255.10.1) 1500->1500 pour le client 192.168.1.8.
Est-ce que cela pose problème? Car je vois pas tout-à-fait ce que c'est.

Merci, Manu

[Invité]

Je vois dans les debugs :

IGMP(0): Received v2 Report on FastEthernet0/1 from 192.168.2.9 for 239.255.10.1
IGMP(0): Received Group record for group 239.255.10.1, mode 2 from 192.168.2.9 for 0 sources

donc a priori le client 192.168.2.9 arrive à créer un Group record.

Alors maintenant, pour faire le point sur ton problème :

1) Tu désactives les debugs,
2) Tu entres 'clear ip mroute *'
3) Tu refais un test de streaming
4) Pendant que le test se déroule, tu entres la commande 'sh ip mroute 239.255.10.1' deux ou trois fois histoire de vérifier qu'on a le même display à chaque fois et tu nous donnes le résultat !

Concernant les messages de MTU, ce sont des "messages cosmétiques". Ils sont liés au fait que le routeur a déterminé si les clients sont du même côté ou non du serveur, le code est donc préparé à d'autres fonctions (pour le RPF check et la gestion de MTU en cas de forwarding entre interfaces notamment).

Edit de mon message : je viens juste de penser à un truc J'ose espérer également que tu as augmenté le TTL dans les Additional Streaming Options, il doit être au minimum à 2 !

Steph

[Emmanuel Bezençon]

J'ai remarqué la même chose après coup, il se connecte bel est bien au groupe.
Voilà les fichiers debug qui pour moi démontrent les mêmes informations à chaque fois que la commande est lancée.
Je sais alors pas quoi en tirer!?

Manu

[Invité]

Le routeur ne crée pas l'entrée (192.168.2.9, 239.255.10.1)...

Cf mon message précédent que j'ai édité mais tu n'as peut-être pas vu...

As-tu modifié le TTL à 2 dans Additional Streaming Options de VLC ?

Steph

[Emmanuel Bezençon]

C'était ça le problème!

Je suis désolé de t'avoir fais chercher autant que ça pour ce seul problème...comme je n'utilise que très peu VLC je n'ai pas remarqué cette configuration et j'y ai pas du tout pensé.
Alors merci beaucoup de tout le temps que tu as investi pour ça!

A bientôt!

[Emmanuel Bezençon]

Je dois citer toutes mes sources dans mon dossier. T'est ok que je cite ton pseudo?
A +

[Invité]

Bonne nouvelle alors

> Je suis désolé de t'avoir fais chercher autant que ça pour ce seul problème...

Quand le problème est connu, ça parait toujours simple !

Ce qui m'a mis la puce à l'oreille, c'est que le client envoyait bien ses Join mais le routeur n'arrivait pas à maintenir une entrée (IP unicast source, IP multicast destination) dans sa mrouting table. C'est souvent caractéristique d'un problème d'IP forwarding. Et là, le TTL m'est revenu en tête.

Bon streaming alors

Steph

[Invité]

Je dois citer toutes mes sources dans mon dossier. T'est ok que je cite ton pseudo?
A +

Si tu veux N'oublie pas de citer developpez.net non plus

Mais le plus important, c'est la méthodologie. Avec les debugs qui vont bien, on a réussi à isoler le problème : un client envoie des IGMP v2 Join, l'entrée (*, IPm) est créée mais le flux (IP unicast, IPm) n'est pas créé dans la mrouting table. Le problème de TTL m'est revenu en tête mais la prochaine étape consistait à utiliser un 'debug ip pack 1' avec une access-list 1 pour filtrer sur 239.255.10.1. Les debugs auraient mis en évidence que les paquets sont droppés à cause du TTL

Bon streaming routé

Steph