Gut, das funkt. Das Problem ist arp:
...
arpwatch: flip flop 192.168.2.251 0:2:44:16:9c:63 (0:2:44:5b:74:ef) eth1
arpwatch: flip flop 192.168.2.251 0:2:44:5b:74:ef (0:2:44:16:9c:63) eth1
arpwatch: flip flop 192.168.2.251 0:2:44:16:9c:63 (0:2:44:5b:74:ef) eth1
arpwatch: flip flop 192.168.2.251 0:2:44:5b:74:ef (0:2:44:16:9c:63) eth1
arpwatch: flip flop 192.168.2.251 0:2:44:16:9c:63 (0:2:44:5b:74:ef) eth1
arpwatch: flip flop 192.168.2.251 0:2:44:5b:74:ef (0:2:44:16:9c:63) eth1
arpwatch: flip flop 192.168.2.251 0:2:44:16:9c:63 (0:2:44:5b:74:ef) eth1
^^^^^^^^^^^^^^^eth1 MAC
arpwatch: flip flop 192.168.2.251 0:2:44:5b:74:ef (0:2:44:16:9c:63) eth1
^^^^^^^^^^^^^^^eth0 MAC
..und das innerhalb 5 Minuten. Selbiges auf eth0. Nun koennt es sich um
die !$#^rtl8139 handeln oder aber um den arpcache. Ein Vesuch das mit
arptable -i eth1 -mac eth0 -j DROP u.ae. in den Griff zu bekommen ist
gescheitert. Beim Deaktivieren von arp an einer eth stirbt der Link.
Die -z Option mit /32 am arpwatch funktioniert nicht. Das Netzwerk
arneitet soweit, aber ich kann mir schlecht vorstellen, dass die
hin- und herspringende arp-Adresse keine negativen Auswirkungen hat.