[SOLVED] PVE Node nach Clusterbeitritt keine Verbindung zum LAN (außerhalb)

[Eyda]

Guten Abend Zusammen,
ich habe einen 3 Node Cluster. Zwei von drei Nodes sind weiterhin im LAN erreichbar. Jedoch ist einer nicht mehr im LAN erreicbar. Seine VM's jedoch schon.
Die Vm's kommen auch weiterhin ins WAN.
Aus der VM raus (welche im Cluster vohanden sind) kann ich den Node auch erreichen.

PVE 6.1-8 (auf allen Nodes)
Der Cluster Health ist in Ordnung.
Der Node lässt sich neustarten.
Die VM's lassen sich starten, stoppen, rebooten und migriren.
Anmerkung: Nodes haben durch ein Dist Upgrade noch alte Interface Namen (alle Nodes).





Erste Frage: Welche Infos werden noch benötigt um überhaupt eine Aussage machen zu können?
Zweite Frage: Ich komm auch mit der Suche inkl Google nicht weiter, da ich nicht weiß wonach ich überhaupt suchen muss. Sollte mir also jemand helfen können, wäre es zusätzlich super wenn man mir sagen könnte wie ich darauf hätte kommen können.

Kontrolliert habe ich die Interface Konfig (hat sich nach Cluster Bildung nicht geändert); den Cluster Status, Firewall (wenn es um WAN Traffic geht); Build-In Firewall; IP-tables, IP Route.
Reboot ist erfolgt.
Kontrolle gegen die anderen Node's.

Danke im Vorraus.

 

[Eyda]

Ergänzung:

Betrieben wird über im PVE auch ein Ceph.
Dieser zeigt folgendes an:
HEALTH_WARN clock skew detected on mon.pve-3

Am Freitag war das Gerät noch regulär erreichbar.
Leider kann ich das grafisch mit >Check_MK nicht darstellen, da Check_MK eine VM im Cluster ist und den Node nachwie vor erreichen kann.

apt install ntp geht leider auch nicht, da der Node ja das WAN nicht erreichen kann.

Ist das alles ein Problem oder eher eine Kaskade an Problemen?

 

[aaron]

Können sich die Nodes untereinander pingen?

Was zeigt ein ip addr show dev vmbr0 und ip addr show dev eno1 an?

 

[Eyda]

root@pve-3:~# ip addr show dev vmbr0 4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 90:b1:1c:2b:5c:5b brd ff:ff:ff:ff:ff:ff inet 192.168.15.144/24 brd 192.168.15.255 scope global vmbr0 valid_lft forever preferred_lft forever

root@pve-3:~# ip addr show dev eno1 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000 link/ether 90:b1:1c:2b:5c:5b brd ff:ff:ff:ff:ff:ff

ja die anderen Node's und VM im Cluster lassen sich pingen. Nur das LAN und WAN außerhalb vom Cluster ist NUR für den Node 3 nicht erreichbar.

 

[aaron]

Verstehe ich das richtig? Node 3 kann die anderen Nodes pingen und von den anderen Nodes gepingt werden? Aber kann nicht den Gateway oder einen anderen Rechner im gleichen Subnetz pingen bzw von einem anderen Rechner gepingt werden?

 

[Eyda]

Verstehe ich das richtig? Node 3 kann die anderen Nodes pingen und von den anderen Nodes gepingt werden? Aber kann nicht den Gateway oder einen anderen Rechner im gleichen Subnetz pingen bzw von einem anderen Rechner gepingt werden?

Genauso ist es richtig . Ergänzung: Node 3 kann alle VM's und CT's im Cluster, welchem er angehört auch pingen.
DeshalB. Node 3 (nicht seine VM'S) kann als einziger nicht den Cluster verlassen bzw. erreicht werden.

 

[aaron]

DeshalB. Node 3 (nicht seine VM'S) kann als einziger nicht den Cluster verlassen bzw. erreicht werden.

Was meinst du mit "nicht den Cluster verlassen"?

Die Situation klingt seltsam :/ Wie sind die Routen eigentlich gesetzt? ip route

 

[Eyda]

Ich bitte um Entschuldigung, wenn das Problem nicht gut genug beschrieben ist.

Also der Node 3 selber kann innerhalb des Clusters (also von jeder VM, Node und jedem CT) angepingt und zb via ssh erreicht werden.
Er selber erreicht diese auch.

Node 1 und 2 kann wie jeder CT und jede VM sowohl das LAN erreichen als auch das WAN.

Node 3 kann dies nicht. Bis Freitag 12 Uhr ging dies.
Kann das irgendwie mit der Zeitumstellung zu tun haben?
Ich bekomme im Ceph Monitor nämlich diese Aussage:
HEALTH_WARN clock skew detected on mon.pve-3

ip Route Ausgabe:

 

[aaron]

Es macht es leider nicht weniger seltsam

Wie sehr ist denn die Zeit daneben? date.

An der Verkabelung oder Switch config hat sich nichts geändert?

 

[Eyda]

Guten Morgen,

clock skew detected on mon.pve-uz-3mon.pve-uz-3 clock skew 8.54002s > max 0.05s (latency 0.000784375s)

Kann ich den Node 3 ohne zusätzliche Pakete, welche installiert werden müssen, gegen Node 1 oder 2 synchronisieren?

An der Verkabelung hat sich nichts verändert. Auch am Switch ist nichts verändert worden.
Bis Freitag 12 Uhr lief es soweit auch.

Nun wird es leider noch seltsamer.
Bis gestern Abend waren unteranderem folgende Ziele vom betroffenen Node Ziele für einen Ping:
x.x.15.159
x.x.15.6
x.x.15.242
8.8.8.8

Alle Ziele außerhalb vom Cluster. Kein Ping funktionierte.

Heute Morgen funktionieren auf einmal ohne zutun folgende Ping Ziele:
x.x.15.159
x.x.15.242

Ich stehe mehr als nur auf dem Schlauch. Wie kann sowas möglich sein?
Eine Überlegung ist, einen weietren Node dem Cluster hinzuzufügen und den betroffenen Node neu aufzusetzen.
Jedoch sollte das meine letzte Option sein, da ich damit vielleicht das Problem wegbekommen kann, aber nicht den Fehler aktiv identifizieren und beheben konnte.

 

[aaron]

Kann es sein, dass die gleiche IP Adresse ein zweites mal Konfiguriert ist?

Hast du vielleicht auch mal mit manuellen MAC Adressen was konfiguriert und versehentlich die gleiche an zwei Stellen in Verwendung?

 

[Eyda]

Also normalerweise ist das nicht möglich,da ich eine Excel Liste mit Mac und IP Adressen pflege. Ganz ausschließen möche ich das jedoch nicht.
Müsste das Problem dann nicht verschwinden wenn ich dem Node eine neue MAC und IP zuwesie?

Kann ich das im PVE Cluster inklusive Ceph überhaupt einfach so?

 

[aaron]

Ich weiß nicht wie dein Netz aufgebaut ist und wie viel verschiedene Geräte du hast, aber es wird wohl leichter sein, dich auf die Suche nach dem schuldigen zu machen. Du kannst ja mal kurz den Server herunter fahren und schauen, ob die IP immer noch im Netz vorhanden ist. Wobei ein Ping hier wahrscheinlich auch nur so halb funktioniert da Windows Rechner per default auf Pings nicht antworten AFAIR.

 

[Eyda]

Hey. Ich habe den Node 3 vom Netz genommen für gute zwei Stunden und Wireshark laufen lassen. Dort ist die IP, noch die Mac Adresse aufgetaucht.
Ich habe gelegentlich FING und angryIP scan laufen lassen. Auch diese zeigten die IP vom Node kein Mal an.

Der Node war vorher weder per SSH noch per Ping von verschiedenen Devices erreichbar.
Müsste ja genau dann eigentlich was zu sehen sein.

Was merkwürdig ist, das telnet von Node 3 gegen 8.8.8.8 im TCPDump zu sehen ist, aber an der Firewall schon nicht mehr. Dazwischen liegt ein Switch und ein Medien Konverter. Selbst ohne Switch ändert sich nichts.

Kann ich den Node nochmal isolieren und im Netz seine IP erneut vergeben für einen Test oder würde das den vorhandenen Cluster gefährden, da hier unter den known hosts die IP eine Zuordnung hat?

 

[Eyda]

Hallo Zusammen,

heute konnte ich endlich das Problem finden und beheben.
Folgendes ist passiert:
Ich habe am Freitag vor der Umschaltung der Uhren kurz ein Verbindungsproblem gehabt mit dem abgestezen Node 3. Als Backup habe ich in unserer Firewall einen Sid2Side VPN vorbereitet gehabt. Diesen habe ich dann mit der IP vom Node 3 im IP Pool bekannt gegeben. Zu diesem Zeitpunkt und auch später wurde dieser VPN nirgendswo in Regeln oder Ähnliches genutzt. Also Referenz 0.

Nachdem die Verbindung aber hergestellt war, habe ich wohl (so denkle ich mir das) nur von den anderen Nodes aus die Erreichbarkeit geprüft.
Montags dann ging es dann los. Ich dachte Anfangs es läge irgendwie an einer Fehlkonfiguration mit dem Schwerpunkt "Zeit". Ab hier seid ihr eingebunden gewesen.

Heute wollte ich den Node also komplett neu aufsetzen und hatte von @aaron noch die IP / MAC Mismatch Thematik im Kopf. Also Node ein letztes mal aus und Win Notebook dran. Bei der IP Vergabe dann die Warnung auf ein IP Mismatch..
Komischerwesie konnte ich nur in dem Notebook selber sehen, dass die IP auf eine falsche MAC Adresse zeigt. Das restliche Netz sieht die MAC vom Node 3 (ARP Flush wurde gemacht).

Naja nach einer kurzen Internet Suche kam dann raus, dass die MAC einer Fortigate gehört. Danach war nur noch ein Konfig-Durchsuchen notwendig.
Node 3 habe ich dann wieder reaktiviert und in den Ceph Cluster eingebracht. Gerade läuft das Remapping.

Ich habe also zu danken...vor allem dir @aaron .

Schönes Wochenende und Ostern euch allen.