Al solucionar un problema general por el cual unLa caja Centos 8 no recibe datos de multidifusión después de enviar un JOIN, el análisis con Wireshark también muestra que el cuadro de Centos no responde a las consultas de membresía de IGMP v2.
En este caso, se ha unido la dirección de multidifusión 225.1.1.3 y se puede confirmar con netstat -g:
# netstat -g
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------- ------ ---------------------
lo 1 224.0.0.1
eth0 1 224.0.0.1
eth1 1 225.1.1.3
Que coincide con la información en/proc/net/igmp
# cat /proc/net/igmp
Idx Device : Count Querier Group Users Timer Reporter
3 eth1 : 3 V3
030101E1 1 0:00000000 0
010101EF 1 0:00000000 0
010000E0 1 0:00000000 0
Pero muy claramente, no envía respuestas al mensaje de consulta de membresía v2:
1881 2544.437502942 192.168.105.253 → 225.1.1.3 IGMPv2 60 Membership Query, specific for group 225.1.1.3
1883 2545.439116776 192.168.105.253 → 225.1.1.3 IGMPv2 60 Membership Query, specific for group 225.1.1.3
1890 2555.526695862 192.168.105.253 → 224.0.0.1 IGMPv2 60 Membership Query, general
1936 2615.525812650 192.168.105.253 → 224.0.0.1 IGMPv2 60 Membership Query, general
1977 2675.524651646 192.168.105.253 → 224.0.0.1 IGMPv2 60 Membership Query, general
1981 2680.487871978 192.168.105.253 → 225.1.1.3 IGMPv2 60 Membership Query, specific for group 225.1.1.3
1983 2681.488403894 192.168.105.253 → 225.1.1.3 IGMPv2 60 Membership Query, specific for group 225.1.1.3
1999 2702.808993240 192.168.117.21 → 224.0.0.22 IGMPv3 54 Membership Report / Leave group 225.1.1.3
2000 2702.826998740 192.168.117.21 → 224.0.0.22 IGMPv3 54 Membership Report / Leave group 225.1.1.3
2002 2704.929915370 192.168.117.21 → 224.0.0.22 IGMPv3 54 Membership Report / Join group 225.1.1.3 for any sources
2003 2705.331977636 192.168.117.21 → 224.0.0.22 IGMPv3 54 Membership Report / Join group 225.1.1.3 for any sources
2023 2735.523170767 192.168.105.253 → 224.0.0.1 IGMPv2 60 Membership Query, general
2063 2795.522407972 192.168.105.253 → 224.0.0.1 IGMPv2 60 Membership Query, general
Varias publicaciones mencionaron deshabilitar el firewall y/o establecer una ruta. Pero el firewall está desactivado y se agregó la ruta. El problema sigue ahí.
¿Cómo se puede configurar Centos8 para responder a las consultas de los miembros?
# systemctl status firewalld
● firewalld.service
Loaded: masked (Reason: Unit firewalld.service is masked.)
Active: inactive (dead)
# ip route
10.1.0.0/16 dev eth2 proto kernel scope link src 10.1.2.21
30.0.0.0/16 dev eth0 proto kernel scope link src 30.0.0.21
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003
169.254.0.0/16 dev eth2 scope link metric 1004
169.254.0.0/16 dev eth3 scope link metric 1005 linkdown
192.168.2.0/24 dev eth3 proto kernel scope link src 192.168.2.21 linkdown
192.168.117.0/24 dev eth1 proto kernel scope link src 192.168.117.21
224.0.0.0/4 dev eth1 scope link
234.0.0.0/8 dev eth1 scope link
235.0.0.0/8 dev eth1 scope link
239.0.0.0/8 dev eth1 scope link
Respuesta1
Aunque lo habíamos net.ipv4.conf.default.rp_filterestablecido en cero, resulta que para deshabilitar completamente la validación de la ruta de retorno, necesitábamos establecer todas las rp_filterconfiguraciones en cero (incluida la lista explícita de la interfaz).
Ponemos un archivo debajo /etc/sysctl.dcomo este:
# Set IGMP Version for eth1
# Set to '2' or '3' depending on what is enabled in the switch
net.ipv4.conf.eth1.force_igmp_version = 2
# Disable source route verification
# In addition to 90-torque.conf, also explicitly set eth1 to ignore
# return path validation
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0