Não estou ciente de nenhuma política de expiração para membros do grupo IGMP dentro da pilha do Linux. Isso pode acontecer, mas eu duvido, já que existem pelo menos duas maneiras para o kernel ser informado (um explícito, o outro implícito) quando a associação IGMP de um programa deve ser descartada.
Portanto, acho que você tem um bug no software que está ouvindo os pacotes multicast. (Cuidado para nomeá-lo?) O programa que recebe o multicast de alguma forma ou deixou cair sua própria associação ou negligenciada para adicionar sua participação no arranque. Ao reiniciar o programa de ouvinte de difusão seletiva, tcpdump
deve ver a solicitação de associação de adição de grupo IGMPv2 + sair na rede.
Você pode muito bem nunca ter notado esse bug ao testar em uma LAN pequena, já que switches de rede baratos não entendem o IGMP. O recurso é chamado de snooping IGMP, e só é encontrado em switches de aproximadamente 5x o custo, por porta, das unidades mais baratas, ou mais. Um switch sem a capacidade de rastreamento do IGMP - ou um com o recurso desativado - transforma o multicast em broadcast, portanto, as mensagens de adição de grupo do IGMP não são necessárias.
Seu provedor de hospedagem aparentemente tem a espionagem IGMP ativada em sua malha de rede, já que as mensagens multicast pararam de chegar depois que a participação no grupo IGMP desapareceu na pilha de rede da máquina com problemas.
Também pode ser que as opções de espionagem IGMP do provedor de hospedagem estejam configuradas incorretamente nos switches, então eles estão descartando a participação no grupo, mas isso não explica o resultado netstat -g
.