Secondary IP Address
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' Aber eine wird nicht aktiv ... host1:~ # ip a s eth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:df:34:e6 brd ff:ff:ff:ff:ff:ff altname enp19s0 altname ens224 inet 10.10.10.41/24 brd 10.10.10.255 scope global eth1 valid_lft forever preferred_lft forever inet 10.10.10.42/24 brd 10.10.10.255 scope global secondary eth1 valid_lft forever preferred_lft forever inet 10.10.10.45/24 brd 10.10.10.255 scope global secondary eth1 valid_lft forever preferred_lft forever wohl weil ... host1:~ # grep "10.10.10.43" /var/log/messages ... host1 wickedd[1212]: eth1: IPv4 duplicate address ipv4 10.10.10.43/24 detected (in use by 48:df:37:67:92:a7)! ================================================================ ... ich find' da nix ... die Adresse ist frei! Aber: host1:~ # ip addr add 10.10.10.43 dev eth1 host1:~ # ip a s eth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:df:34:e6 brd ff:ff:ff:ff:ff:ff altname enp19s0 altname ens224 inet 10.10.10.41/24 brd 10.10.10.255 scope global eth1 valid_lft forever preferred_lft forever inet 10.10.10.42/24 brd 10.10.10.255 scope global secondary eth1 valid_lft forever preferred_lft forever inet 10.10.10.45/24 brd 10.10.10.255 scope global secondary eth1 valid_lft forever preferred_lft forever inet 10.10.10.43/24 scope global secondary eth1 valid_lft forever preferred_lft forever ================================================================ Häh? Was verstehe ich wieder nicht? Bernd
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 hier https://maclookup.app/macaddress/48df37 und an vielen anderen Stellen als zu "Hewlett Packard Enterprise" gehörend bezeichnet. Ein Drucker oder Scanner, der nur bei Bedarf eingeschaltet wird? -- Viele Grüße Michael
Am 10.01.24 um 10:47 schrieb bnacht:
Am 10.01.24 um 10:34 schrieb Michael Behrens:
Das ist die falsche Schlussfolgerung. Niemand hindert Dich, eine IP zu konfigurieren, die schon ein anderes Gerät benutzt.
Ein grep -r "10.10.10.43" /etc/* zeigt auch keine weiteren Einträge.
Auf dem /Drucker/? Viele Grüße Ulf
OK, ein separates systemctl restart wickedd.service hat geholfen (oder das ich nun lange genug Zeit damit verbracht habe die Ursache zu suchen und nun irgendein Cache abgelaufen, oder ...) Ich dachte beim beenden von yast lan wird automatisch wickedd.service neu gestartet ... Bernd Am 10.01.24 um 10:08 schrieb bnacht:
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:
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
Am 11.01.24 um 06:34 schrieb Manfred Haertel, DB3HM:
... aber bis man den richtigen Switch findet ;-) Wie geschrieben, das Problem hat sich erledigt. Entweder weil ein Cache irgendwo abgelaufen war, oder weil der Wickedd restart es erledigt hat. Cached ESX eigentlich die einkommenden MAC-Adressen?
bnacht schrieb:
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
Am 10.01.24 um 11:14 schrieb bnacht:
... Hi, davon bin ich nicht so recht überzeugt. Was auch immer Yast da anzeigt, ich habe mehrfach festgestellt, dass man nach Änderungen der Netzwerkkonfig definitiv manuell systemctl restart network aufrufen sollte (z.B. vorher per DHCP im Netz erhaltene IPs nicht auf lokal statisch konfigurierte umgestellt)... Wenn man nicht grad im Hochverfügbarkeits-Modus ist, sollte das ja auch kein Problem sein. -- cu jth
bnacht schrieb:
Sicher, man könnte unterschiedliche Dienste an unterschiedliche IPs "binden". Aber wozu sollte man das tun? Und wenn mal was nicht funktioniert, wird die Fehlersuche ein Alptraum. Wir hatten mal - zugegeben vor langer Zeit - auf der Arbeit auch mal so einen Fall gehabt, wo wir glaubten, mehrere virtuellen IPs auf demselben Interface im selben Subnetz seien die Lösung und es gab dann immer wieder Phänomene. Von da ab war das ein No-Go und wir haben das nie wieder gemacht. Eigentlich gibt es in solchen Fällen auch eigentlich immer eine bessere Lösung - daher die Frage: Was ist das eigentliche Ziel? -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
bnacht schrieb:
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
On 11.01.24 08:37, Manfred Haertel, DB3HM wrote:
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.
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. Viele Grüße Ulf
Ulf Volmer schrieb:
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.
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
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 hier https://maclookup.app/macaddress/48df37 und an vielen anderen Stellen als zu "Hewlett Packard Enterprise" gehörend bezeichnet. Ein Drucker oder Scanner, der nur bei Bedarf eingeschaltet wird? -- Viele Grüße Michael
Am 10.01.24 um 10:47 schrieb bnacht:
Am 10.01.24 um 10:34 schrieb Michael Behrens:
Das ist die falsche Schlussfolgerung. Niemand hindert Dich, eine IP zu konfigurieren, die schon ein anderes Gerät benutzt.
Ein grep -r "10.10.10.43" /etc/* zeigt auch keine weiteren Einträge.
Auf dem /Drucker/? Viele Grüße Ulf
OK, ein separates systemctl restart wickedd.service hat geholfen (oder das ich nun lange genug Zeit damit verbracht habe die Ursache zu suchen und nun irgendein Cache abgelaufen, oder ...) Ich dachte beim beenden von yast lan wird automatisch wickedd.service neu gestartet ... Bernd Am 10.01.24 um 10:08 schrieb bnacht:
participants (5)
-
bnacht -
Jörg Thümmler -
Manfred Haertel, DB3HM -
Michael Behrens -
Ulf Volmer