Estou tentando entender um problema estranho de queda de pacotes ao entrar em um determinado grupo multicast.
Eu acho que esse problema está relacionado ao patch introduzido no kernel ver 2.6.37
Beginning with kernel 2.6.37, it has been changed the meaning of dropped
packet count. Before, dropped packets was most likely due to an error.
Now, the rx_dropped counter shows statistics for dropped frames because
of:
Softnet backlog full -- (Measured from /proc/net/softnet_stat)
Bad / Unintended VLAN tags
Unknown / Unregistered protocols
IPv6 frames when the server is not configured for IPv6
If any frames meet those conditions, they are dropped before the
protocol stack and the rx_dropped counter is incremented.
Em um SLES11 SP3 limpo, consegui reproduzir isso unindo o grupo multicast STP (01: 80: c2: 00: 00: 00).
Sem nenhuma alteração, não há quedas de pacotes em /proc/net/dev (RX) ou netstat -i porque meu sistema não se uniu ao grupo multicast STP (ignorando assim os pacotes).
Quando eu participo do grupo multicast STP eu posso ver pacotes dropados (1 pacote a cada 2 segundos) que eu acredito que foram descartados devido ao patch introduzido no kernel 2.6.37 (Unknown / Unregistered Protocols) e está ok.
hostname:~ # ip maddr add 01:80:c2:00:00:00 dev eth1
Meu entendimento é que quando eu modifico o módulo llc / stp no kernel, ele reconhece o protocolo e, portanto, pára de soltar os pacotes (os testes provam que estou certo).
Modprobing llc ou stp module (depende de llc) "corrige" problema com o pacote descartado.
Agora, a pergunta:
Eu tenho um aplicativo que une vários grupos de multicast quando iniciado. E, por algum motivo, um um Participe em particular dispara um problema de pacote descartado (1 pacote por 2 segundos).
O problema é que não é não stp multicast address 01:80:c2:00:00:00 , mas totalmente diferente ( 01:00:5e:46:ac:04 aka 239.70.172.4 ).
A inserção do módulo llc / stp "correções" descartou o incremento do contador de pacotes. Todos os outros grupos multicast não causam este problema, por ex. ( 01:00:5e:46:ac:02 ) e também muitos outros.
Os quadros STP são os únicos que aparecem na interface a cada 2 segundos, mas o endereço MAC de destino é 01: 80: c2: 00: 00: 00.
00:21:1b:4f:a3:bf > 01:80:c2:00:00:00, 802.3, length 119: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1s, Rapid STP, CIST Flags [Learn, Forward]
Como isso é possível? Por que 01: 00: 5e: 46: ac: 04 grupo multicast acionaria esse comportamento, como seria de alguma forma relacionado ao grupo STP e deixaria quadros / pacotes passarem pela pilha?