есть комп.
на нем свежепоставленный Debian Etch
наблюдается явление, называемое arp flux
выглядит, как задержка arp ответа секунд, так на 10..

eth0 - виртуальный интерфейс для ieee1394 (не нужен, был из коробки)
eth1 - смотрит в сеть (к нему и идет тот запрос)

$ ip l
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0e:a6:6e:9c:ed brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ieee1394 00:e0:18:00:00:61:31:da brd ff:ff:ff:ff:ff:ff:ff:ff
4: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0

нашел вот это:
http://linux-ip.net/html/ether-arp.html
http://wiki.openvz.org/Multiple_Network_Interfaces_And_ARP_Flux

делаю (пробовал в разных комбинациях и пр.):
sysctl -w net.ipv4.conf.all.arp_filter=1
sysctl -w net.ipv4.conf.all.arp_announce=2
sysctl -w net.ipv4.conf.all.arp_ignore=2

ситуация совершенно не меняется.

думаю попробовать искоренить eth0.. есть смысл??

как можно избавится от задержки arp???... жутко бесит.
заранее большое спасибо!!!

• arp flux,tx2, 10:23 , 20-Ноя-07

выкидывать eth0 (rmmod eth1394) - пробовал - без эффекта

еще пробовал отловить tcpdump -i any на самом сервере в тот момент когда шлю arp запрос...
из 10 попыток - поймать не удалось. :(

на данный момент стоит костыль в виде arping в crontab... идиотизм конечно, но действенный.
хотелось бы корректного решения...

повторюсь на счет внешних проявлений:
если долго не трогать этот комп(ТЕ он теряется из arp-кеша компов и из его кеша теряются другие компы), то при попытке подключения, например по ssh, возникает задержка в 9-11 сек. снифер говорит что задержка между запросом и ответом arp

(мож у меня совсем глаза "замылены" и я не вижу чегото простого и очевидного?)