Am 10.01.24 um 10:08 schrieb bnacht:

...

10.10.10.43/24 detected (in use by 48:df:37:67:92:a7)!

Hast du denn ein Gerät mit dieser MAC-Adresse? Das vielleicht nur manchmal aktiv ist?

Oder - vielleicht weiß jemand hier mehr - hat wicked da was im Cache oder in der Konfiguration, das besser nicht mehr drin wäre?

48:df:37 wird als zu "Hewlett Packard Enterprise" gehörend bezeichnet. Ein Drucker oder Scanner, der nur bei Bedarf eingeschaltet wird? Nee, die Adresse ist definitiv frei. Sonst könnte ich sie ja auch nicht

Am 10.01.24 um 10:34 schrieb Michael Behrens: per ip addr add hinzufügen. Denn dann funktioniert sie ja. Ein grep -r "10.10.10.43" /etc/* zeigt auch keine weiteren Einträge. Bernd

Am 10.01.24 um 12:41 schrieb Ulf Volmer:

Am 10.01.24 um 10:47 schrieb bnacht:

...

Am 10.01.24 um 10:34 schrieb Michael Behrens:

...

...

48:df:37 wird als zu "Hewlett Packard Enterprise" gehörend bezeichnet. Ein Drucker oder Scanner, der nur bei Bedarf eingeschaltet wird? Nee, die Adresse ist definitiv frei. Sonst könnte ich sie ja auch nicht per ip addr add hinzufügen. Denn dann funktioniert sie ja.

Das ist die falsche Schlussfolgerung. Niemand hindert Dich, eine IP zu konfigurieren, die schon ein anderes Gerät benutzt. Na ja, ... im log stand ja schon das sie als belegt erkannt wurde ... Da sie dann nicht gesetzt war gehe ich mal davon aus das da etwas zwischen ist was verhindert das eine IP-Adresse die schon im Netz ist erneut gebunden wird.

...

Ein grep -r "10.10.10.43" /etc/* zeigt auch keine weiteren Einträge.

Auf dem /Drucker/? ?? Welcher Drucker?

Wobei es mich nicht wundern würde, wenn das Problem wieder auftaucht, sobald das Gerät mit der MAC 48:df:37:67:92:a7 wieder im LAN auftaucht. Ich kann mir kaum vorstellen, dass sich wickedd Phantasie-MACs ausdenkt, um die Arbeit zu verweigern. Am 10.01.24 um 11:14 schrieb bnacht:

... host1 wickedd[1212]: eth1: IPv4 duplicate address ipv4 10.10.10.43/24 detected (in use by 48:df:37:67:92:a7)!

-- Viele Grüße Michael

bnacht schrieb:

Am 10.01.24 um 11:41 schrieb Michael Behrens:

...

Wobei es mich nicht wundern würde, wenn das Problem wieder auftaucht, sobald das Gerät mit der MAC 48:df:37:67:92:a7 wieder im LAN auftaucht. Ich kann mir kaum vorstellen, dass sich wickedd Phantasie-MACs ausdenkt, um die Arbeit zu verweigern. Das Gerät ist seit gestern weg vom Netz! (Kabel ab) Sollte also nicht passieren.

Der ARP-Eintrag in anderen Systemen FÜR das abgeschaltete System bleibt aber manchmal länger erhalten, teilweise ewig. Eigentlich sollte er nach einer konfigurierbaren Zeit (Minuten-Bereich) verschwinden, aber unter bestimmten Voraussetzungen scheint das nicht zu funktionieren. Bislang hatte ich noch nicht die Muße, dem Problem mal nachzugehen. Aber ich habe das auch auf Netzen auf der Arbeit schon öfter beobachtet. Und dann hilft natürlich ein Durchstarten des Netzwerkes, wenn dabei der ARP-Cache gelöscht wird... -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

bnacht schrieb:

Am 11.01.24 um 06:34 schrieb Manfred Haertel, DB3HM:

...

bnacht schrieb:

...

Am 10.01.24 um 11:41 schrieb Michael Behrens:

...

Wobei es mich nicht wundern würde, wenn das Problem wieder auftaucht, sobald das Gerät mit der MAC 48:df:37:67:92:a7 wieder im LAN auftaucht. Ich kann mir kaum vorstellen, dass sich wickedd Phantasie-MACs ausdenkt, um die Arbeit zu verweigern. Das Gerät ist seit gestern weg vom Netz! (Kabel ab) Sollte also nicht passieren.

Der ARP-Eintrag in anderen Systemen FÜR das abgeschaltete System bleibt aber manchmal länger erhalten, teilweise ewig.

Eigentlich sollte er nach einer konfigurierbaren Zeit (Minuten-Bereich) verschwinden, aber unter bestimmten Voraussetzungen scheint das nicht zu funktionieren.

Bislang hatte ich noch nicht die Muße, dem Problem mal nachzugehen. Aber ich habe das auch auf Netzen auf der Arbeit schon öfter beobachtet.

Und dann hilft natürlich ein Durchstarten des Netzwerkes, wenn dabei der ARP-Cache gelöscht wird...

... aber bis man den richtigen Switch findet ;-)

Der Switch hat damit höchstwahrscheinlich gar nichts zu tun. Der führt zwar auch eine Liste von MAC-Adressen, aber dafür, um zu wissen, welche MAC-Adresse er über welchen Port erreichen kann. Sieht er sie einmal "woanders", lernt er sofort um. Und wenn er die MAC-Adresse gar nicht kennt, schickt er die Pakete an selbige über ALLE Ports. Damit verteilt er die Pakete FAST immer so, dass sie am richtigen Ziel ankommen. Der einzig "kritische" Fall ist der, dass eine MAC-Adresse plötzlich an einem anderen Port hängt, sich aber selbst nicht regt. In dem Fall muss man also den "umgehängten" Knoten veranlassen, selber Traffic zu machen, dann ist wieder alles OK. Dein Problem war aber gar nicht auf der MAC-Ebene, sondern einen Layer höher auf der IP-Ebene. Ich vermute stark, dass der ARP-Eintrag für die ALTE IP auf dem Knoten noch da war, der die IP neu gekriegt hat und das die Probleme verursacht hat. Die ARP-Table auf dem Knoten und die MAC-Table auf den Switches sind zwei Dinge, die nichts miteinander zu tun haben. Die ARP-Table ist schlicht eine Zuordnung MAC<->IP und die Switches führen eine Zuordnung MAC<->Port und interessieren sich gar nicht für IPs. Du hattest aber ein Problem mit einer IP.

Wie geschrieben, das Problem hat sich erledigt. Entweder weil ein Cache irgendwo abgelaufen war, oder weil der Wickedd restart es erledigt hat.

Ohne es selber ausprobiert zu haben würde ich annehmen, dass ein Restart von Wicked die ARP-Table löscht.

Cached ESX eigentlich die einkommenden MAC-Adressen?

Kommt drauf an. :-) Das Console-Betriebssystem von ESX ist ja ein Linux und das hat denselben ARP-Cache wie jedes andere Linux auch (auch mit denselben Fehlern :-)). Aber das ist für Deine Frage vermutlich nicht relevant. Ansonsten hat man aber im ESX einen virtuellen Switch. Der läuft unter dem VMKernel von VMware, aber das ist auch kaum relevant, weil es eben ein Switch ist. Also hat der keinen ARP-Cache, aber einen MAC-Adress-Cache, um die Pakete richtig auf die Ports verteilen zu können (also in dem Fall an die richtigen VMs zuzustellen). Somit gilt wieder das oben genannte, also man hat nur ein Problem, wenn eine MAC plötzlich an einem anderen (virtuellen) Port hängt und sich ruhig verhält. Das hat aber mit Deinem Problem wohl wieder nichts zu tun. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

bnacht schrieb:

Am 11.01.24 um 06:41 schrieb Manfred Haertel, DB3HM:

...

bnacht schrieb:

...

Hi,

ich habe drei secondary IP-Adressen via YaSt eingetragen.

================================================================ host1:~ # cat  /etc/sysconfig/network/ifcfg-eth1 IPADDR='10.10.10.41/24' IPADDR_1='10.10.10.42/24' IPADDR_2='10.10.10.43/24' IPADDR_3='10.10.10.45/24' BOOTPROTO='static' STARTMODE='auto' ZONE='public' Es hat zwar wahrscheinlich erst mal nichts mit dem geschilderten Problem zu tun, aber mir stellt sich schon die Frage: Was ist das Ziel des ganzen? Denn alle vier Adressen sind im selben Subnetz.

Sicher, man könnte unterschiedliche Dienste an unterschiedliche IPs "binden". Aber wozu sollte man das tun? Um bei einer Migration mit Konsolidierung externen Geräten die bekannten IP präsentieren zu können.

OK, das ist ein Grund - aber aus der alten Erfahrung heraus würde ich das IMMER anders lösen als mit mehreren Adressen im selben Subnetz auf dem selben Interface. Das geht ja schon mit den ausgehenden Paketen los: Welche Source-IP-Adresse haben die denn, wenn sie einen Knoten im selben Subnetz adressieren? Denn "passen" würden ja alle vier. Es ist nicht immer sicher (zumindest nicht ohne weitere Maßnahmen), dass die genommen wird, die man gerne hätte. Das ist wirklich eine Einladung für unerwartete "Phänomene" im Netzwerk. Ich würde immer zuerst versuchen, die IP auf den Clients, die sie benutzt haben, zu ändern. Man wird das eh irgendwann mal tun müssen und mit einem Workaround schiebt man den Zeitpunkt, wo man in diesem sauren Apfel beißen muss, nur hinaus und sorgt dafür, dass die IPs nie geändert werden - schon gar nicht, wenn z.B. im beruflichen Umfeld andere Leute für die Clients verantwortlich sind und man die überzeugen muss, die IP zu ändern. Da ist eine Server-Konsolidierung ein gutes Argument, ein halbes Jahr später ist "ich will das jetzt aber so" ein schlechtes Argument (weil es ging ja die ganze Zeit)... Und wenn es gar nicht anders geht würde ich an geeigneter Stelle zu einem NATing greifen (wenn das geht, weil das Netzwerk eine geeignete Routing-Struktur ist - oder man NATet direkt auf dem Betriebssystem des Clients, wenn keiner sich traut, die Anwendung anzupassen, weil die IP drin hard codiert ist und der Source-Code nicht mehr da ist - soll es alles geben...). Das ist zwar auch intransparent, aber keine Einladung für Phänomene. Ich weiß ja nicht, ob das betroffene Netz bei Dir im Wohnzimmer oder auf der Arbeit steht. Zuhause wäre es wohl egal. Aber auf der Arbeit würde ich so ein Übergangs-Konstrukt eher nicht machen - ist halt traurige Erfahrung... -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

Ulf Volmer schrieb:

On 11.01.24 08:37, Manfred Haertel, DB3HM wrote:

...

Das geht ja schon mit den ausgehenden Paketen los: Welche Source-IP-Adresse haben die denn, wenn sie einen Knoten im selben Subnetz adressieren? Denn "passen" würden ja alle vier. Es ist nicht immer sicher (zumindest nicht ohne weitere Maßnahmen), dass die genommen wird, die man gerne hätte. Das ist wirklich eine Einladung für unerwartete "Phänomene" im Netzwerk.

Ausgehende, **neue** Verbindungen verwenden die /primäre/ IP, das ist üblicherweise die erste konfigurierete. Anworten auf Anfragen verwenden die Adresse, an die die Anfrage geschickt wird. Also alles gut.

Das mag so sein, wenn das im Kernel so implementiert ist. Nach meiner Kenntnis ist das aber Implementations-abhängig. Und ob es das ist, was man bei einer Server-Konsolidierung ERWARTET, ist noch mal eine andere Frage. Da kann es ja sein, dass ein Client eben die ANDERE IP erwartet, unter der er auch den Server kontaktiert, weil es eben die IP des alten Servers ist. Kann, nicht muss - aber das sind Fallen, die tief irgendwo in Applikationen versteckt sind und die man nur schwer findet. Ich bleibe dabei, ich würde es nicht (mehr) machen und habe auch früher schon schlechte Erfahrungen damit gemacht. Das ist mein Rat, andere mögen das anders sehen.

...

Ich würde immer zuerst versuchen, die IP auf den Clients, die sie benutzt haben, zu ändern. Man wird das eh irgendwann mal tun müssen und mit einem Workaround schiebt man den Zeitpunkt, wo man in diesem sauren Apfel beißen muss, nur hinaus und sorgt dafür, dass die IPs nie geändert werden - schon gar nicht, wenn z.B. im beruflichen Umfeld andere Leute für die Clients verantwortlich sind und man die überzeugen muss, die IP zu ändern. Da ist eine Server-Konsolidierung ein gutes Argument, ein halbes Jahr später ist "ich will das jetzt aber so" ein schlechtes Argument (weil es ging ja die ganze Zeit)...

Es ist halt häufig so, gerade im beruflichen Umfeld, dass man nicht alles beteiligten Geräte (Clients, Firewalls und Co.) im Zugriff hat.

Da macht man sich das Leben einfacher, wenn man, wie bnacht, dem Dienst eine dedizierte IP gibt, die man später mit migrieren kann.

Wenn ich "bnacht" richtig verstanden habe, ging es ihm um den konkreten Fall der Migration unter Beibehaltung der IP und eben nicht um eine strukturelle Maßnahme, um eine spätere Migration zu vereinfachen. Und das würde ich mit derselben Argumentation eben nicht machen, denn in DEM Moment ist ja auch bei den anderen Leuten die Einsicht, eine Änderung machen zu müssen, am größten. Bei mir auf der Arbeit war es in den letzten Jahren vor meiner Rente so, dass eh (fast) alle Server virtualisiert waren und es ohnehin keinen Sinn gemacht hätte, zwei Server-Funktionen auf derselben VM zu betreiben. Dann lieber für einen neuen Server-Dienst eine neue VM einrichten, die ist in wenigen Minuten betriebssystemmäßig aufgesetzt und hat sowieso eine eigene IP - und da dann den neuen Server-Dienst drauf. Da die Anzahl der Server-Dienste langsamer wuchs als Hauptspeicher und Massenspeicher immer größer und gleichzeitig billiger pro Datenmenge wurden, funktionierte das gut. Und dann stellten sich Fragen wie mehrere IPs im selben Subnetz auf derselben Maschine nicht wirklich. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel