Eu não sei se isso vai ajudar, mas acabei encontrando um problema parecido enquanto resolvo problemas em dois guests Linux KVM, cada um executando o Ubuntu 10.04. Descobri que, ao executar o tcpdump -i eth1, veria os endereços multicast (que é uma sub-rede diferente do IP designado para a NIC), mas se eu executasse o tcpdump -i, não o faria. Fiz alguns testes adicionais do tcpdump enquanto monitorava o dmesg e descobri que quando eu usava o dispositivo eth1 no tcpdump ele colocava o NIC em promíscuo, mas ao usar o dispositivo "any", nem o eth0 nem o eth1 eram promíscuos. Isso é contrário a como ele é manipulado em um host físico em que "any" coloca todos os NICs em promíscuos ou, pelo menos, nos hosts com os quais testei.
Eu executei o comando ip link set eth1 promisc on e, quando usei o dispositivo "any", agora ele podia ver o tráfego. Isso se aplica igualmente a eth0, mas eu sei que o tráfego que eu queria não estava chegando lá, então eu só fiz isso para testar. Você pode salvar isso para o host editando / etc / network / interfaces e adicionando uma linha que começa com "post-up" seguida do comando que você acabou de usar e isso garante que o dispositivo seja promíscuo quando o melhor for inicializado.
Eu não acredito que um NIC normalmente precisaria ser promíscuo para ver o tráfego multicast, mas nesse caso com o convidado KVM, parece que era esse o caso e ele aparece se o dispositivo não estiver definido como promíscuo e só virá IP pacotes em uma sub-rede com o mesmo IP que o NIC, se não em promíscuo. O Snort usa o libpcap, a mesma biblioteca do tcpdump IIRC e, se ele está tentando se tornar promíscuo através de qualquer interface, parece que não está conseguindo o que deveria. Eu não acredito que keepalive requer promiscuous em circunstâncias normais, mas neste caso parece ser a única maneira de ver o tráfego multicast.
Espero que isso ajude.