Pues creo que encontré exactamente el problema, aunque la solución no es ni mucho menos "viable" hasta que no lo corrigan.
El módulo ARP del kernel del router falla o no obedece la directiva mcast_solicit. Por defecto, cuando un host deja de ser alcanzable, pasa por una cadena de intentos para reencontrarlo, y si todo ello falla por último, como última opción envía una petición ARP broadcast. Esta petición si logra una contestación positiva hace que la tabla ARP se actualice y se marque dicho host como activo, pero si no hay respuesta, se marca la entrada ARP como fallída.
mcas_solicit establece precisamente el número de intentos/peticiones ARP broadcast que se van a realizar antes de que se marque como fallida, y su valor por defecto es 3. El problema es que aunque en el Mitrastar está establecido a 3, al sistema le da exactamente igual que sean 3 o 100. Es decir, no se respeta dicho límite.
La única solución que parece funcionar es estableciendo directamente mcast_solicit a cero, es decir, después de intentar los otros modos de resolución, no se enviará ni un solo paquete broadcast para ARP request. En cuanto se hace, todo el tráfico ARP que inundaba desaparece (quedando tan solo el tráfico ARP normal). Esto podría traer quizás algún efecto no deseado, pero...
En cualquier modo para poder realiar esto habría que hacerlo modificando el archivo de configuración directamente, y el cambio no sería permanente (hasta el siguiente reinicio), para que fuese persistente habría que complicarse aun más la vida. Se haría así desde la shell:
echo 0 > /proc/sys/net/ipv4/neigh/br0/mcast_solicit
Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
.... 