Ao solucionar um problema geral, por que umA caixa Centos 8 não recebe dados multicast após enviar um JOIN, a análise com wireshark também mostra que a caixa Centos não responde às consultas de associação do IGMP v2.
Neste caso, o endereço multicast 225.1.1.3 foi unido e pode ser confirmado com 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
O que corresponde às informações em/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
Mas muito claramente, ele não está enviando respostas à mensagem de consulta de associação 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
Várias postagens mencionaram a desativação do firewall e/ou a configuração de uma rota. Mas o firewall está desativado e a rota foi adicionada. O problema ainda está lá.
Como configurar o Centos8 para responder às dúvidas de adesão?
# 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
Responder1
Embora tenhamos net.ipv4.conf.default.rp_filterdefinido como zero, para desabilitar totalmente a validação do caminho de retorno, precisávamos definir todas as rp_filterconfigurações como zero (incluindo listar explicitamente a interface).
Colocamos um arquivo /etc/sysctl.dassim:
# 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