arp problem in /var/log/messages

[parcival39]

Hallo zusammen,
sehe folgendes in /var/log/messages:

+++ /tmp/security.oE7cPuZd 2010-04-26 03:01:45.000000000 +0200
+arp: 192.168.100.155 moved from 00:50:56:b5:79:85 to 00:50:56:b5:08:38 on em0
+arp: 192.168.100.155 moved from 00:50:56:b5:79:85 to 00:50:56:b5:08:38 on em0
+arp: 192.168.100.155 moved from 00:50:56:b5:79:85 to 00:50:56:b5:08:38 on em0

Wobei es sich bei dem 192.168.100.155 um einen DNS Server handelt (linux), der zwei
NIC hat im selben Subnet. Jeweils eine NIC für den internal / external View. Beide Server FreeBSD 8.0 und besagter Linux laufen virtuell (ESX4) in einer DMZ.
Als Standardgateway dient die Firewall (Juniper SSG). Alles läuft auch ohne Problem, mich wundert nur die Reklamtion seitens FreeBSD. Hat ev. FreeBSD Probleme mit den
virtuellen Switches von VMWare ESX4 ?

Danke für jeden Tipp

Stefan

 

[britneyfreek]

ist ein dhcp involviert?
ansonsten könnte ich mir durchaus vorstellen, dass die virtuellen switche einen "bug" haben.
sorry, keine konkrete idee.

 

[Bummibaer]

Hi,

ich weiss zwar ned was ein virtueller Switch sei soll abär:
-> em0 bekommt Pakete von IP 192.168.100.155, wobei der Rechner mit der IP 192.168.100.155 zwei NICs im selben Netz hat. Mit großer Wahrscheinlichkeit haben diese Pakete die selbe SRC IP aber werden mal über die NIC1 und mal über die NIC2 des Rechners mit der IP 192.168.100.155 verschickt. Das sieht dann aus sicht von ARP genau so aus, da die MAC Adressen ja unterschiedlich sans von de NIC1 und NIC2.

Möglichkeit 1:
- Dienste fest an IP binden und guggen das Karte 1 oder 2 die hat und ned beide als SRC für den Versand auftreten und unterschiedliche IPs ham

Möglichkeit 2:
- die zwei NIC (1+2) oifach bündeln wenn es drum geht mehr Bandbreite zu ham und der gebündelten virtuellen die Ip zuweisen

Möglichkeit 3:
- die zwei NIC als filover konfigurieren wenn das der Sinn der Sache sein sollte und schauen das immer nur die selbe schuftet und solang dem so is die zweite NIC die Schnautze hält

Möglichkeit 4:
- arp Warnungen oifach per sysctl bärig fein abschalten für den Fall, dann hast Du zwar das selbe "Problem", bekommst abär die Meldungen nimma

Gruß Bär

 

[reakktor]

Hi,
-> em0 bekommt Pakete von IP 192.168.100.155, wobei der Rechner mit der IP 192.168.100.155 zwei NICs im selben Netz hat. Mit großer Wahrscheinlichkeit haben diese Pakete die selbe SRC IP aber werden mal über die NIC1 und mal über die NIC2 des Rechners mit der IP 192.168.100.155 verschickt. Das sieht dann aus sicht von ARP genau so aus, da die MAC Adressen ja unterschiedlich sans von de NIC1 und NIC2.

Denke das ist genau korrekt so - wenn der Verkehr über mehrer Interfaces läuft, die sich eine IP teilen, dann passiert genau so was.

Habe das Symptom ebenfalls:
Apr 30 14:40:58 backupserv kernel: arp: 192.168.10.2 moved from 00:1a:64:d2:de:3c to 00:1a:64:d2:de:3e on em0
Apr 30 14:40:58 backupserv kernel: arp: 192.168.10.2 moved from 00:1a:64:d2:de:3e to 00:1a:64:d2:de:3c on em0
Apr 30 14:42:06 backupserv kernel: arp: 192.168.10.2 moved from 00:1a:64:d2:de:3c to 00:1a:64:d2:de:3e on em0

Hier sind 2 NICs gebündelt für größere Bandbreite - insofern hier alles normal, die ARP-Wechsler sind also logisch und zu erwarten.
Wenn es zu den arp-Warnungen ohne dass man das geplant hat, läuft der Traffic wohl an einer Stelle über zwei Interfaces mit verschiedenen MAC-Adressen, aber mit der selben IP - tippe hier auf eine Bridge zwischen echtem und virtuellem Interface.

Sollte alles funktionieren, Meldungen ignrorieren oder abschalten