1 votes

L'une des deux machines sur le même réseau ne reçoit pas les membres du groupe multicast.

Dans un réseau distant, nous avons deux machines. l'une d'entre elles reçoit des abonnements multicast, une autre non.

La machine 1 ne reçoit que des requêtes igmp :

sudo tcpdump -nevv -i eth1 -s 1515 igmp
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 1515 bytes
09:42:12.973995 00:24:97:23:54:3f > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: (tos 0xc0, ttl 1, id 13227, offset 0, flags [none], proto IGMP (2), length 32, options (RA))
    157.157.7.252 > 224.0.0.1: igmp query v2

alors que la machine 2 reçoit beaucoup plus de paquets igmp :

09:46:12.986376 00:24:97:23:54:3f > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: (tos 0xc0, ttl 1, id 13468, offset 0, flags [none], proto IGMP (2), length 32, options (RA))
    157.157.7.252 > 224.0.0.1: igmp query v2
09:46:13.148086 00:e0:81:b3:f7:66 > 01:00:5e:14:14:8b, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    192.168.21.12 > 230.20.20.139: igmp v2 report 230.20.20.139
09:46:13.384097 00:e0:81:b3:f7:66 > 01:00:5e:1e:1e:6e, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    192.168.21.12 > 231.30.30.110: igmp v2 report 231.30.30.110
09:46:15.056105 00:e0:81:b3:f7:66 > 01:00:5e:14:14:b7, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    192.168.21.12 > 231.20.20.183: igmp v2 report 231.20.20.183
09:46:15.212094 00:e0:81:b3:f7:66 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    192.168.21.12 > 224.0.0.251: igmp v2 report 224.0.0.251
09:46:15.900096 00:e0:81:b3:f7:66 > 01:00:5e:14:14:24, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    192.168.21.12 > 230.20.20.36: igmp v2 report 230.20.20.36
09:46:16.036096 00:e0:81:b3:f7:66 > 01:00:5e:1d:1d:99, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    192.168.21.12 > 231.29.29.153: igmp v2 report 231.29.29.153
09:46:18.764102 00:e0:81:b3:f7:66 > 01:00:5e:14:14:8a, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    192.168.21.12 > 230.20.20.138: igmp v2 report 230.20.20.138
09:46:21.612091 00:e0:81:b3:f7:66 > 01:00:5e:14:14:08, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    192.168.21.12 > 231.20.20.8: igmp v2 report 231.20.20.8
09:46:22.764102 00:e0:81:b3:f7:66 > 01:00:5e:14:14:70, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    192.168.21.12 > 230.20.20.112: igmp v2 report 230.20.20.112
09:46:22.956111 00:e0:81:b3:f7:66 > 01:00:5e:14:14:85, ethertype IPv4 (0x0800), length 46: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
    192.168.21.12 > 230.20.20.133: igmp v2 report 230.20.20.133

dans les deux cas, les routes le sont :

224.0.0.0       *               240.0.0.0       U     0      0        0

même lan, pas de pare-feu, pas de règles iptables, et ça marchait bien avant la panne

La machine qui ne fonctionne pas est ubuntu 14, celle qui fonctionne est debian jessie.

J'ai essayé de tester avec iperf, la machine ubuntu peut envoyer des paquets multicast mais ne peut pas les recevoir.

Qu'est-ce qui pourrait être vérifié d'autre ?

1voto

stambata Points 1598

Passer à IGMPv2 sur Ubuntu

echo "2" > /proc/sys/net/ipv4/conf/eth1/force_igmp_version

et réessayez. Si vous avez le même problème, vérifiez Filtrage du chemin inverse

cat /proc/sys/net/ipv4/conf/default/rp_filter

1 indique, que le noyau fera la validation de la source en confirmant le chemin inverse.

0 indique, pas de validation de la source.

utiliser 0

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X