Hallo Leute!
Nachdem ich gestern den ganzen Tag geflucht habe und am Ende die VM auf meinem Server mit NAT eingerichtet habe, bin jetzt auf die Suche nach dem Problem (ja, das Problem hätte ich gestern suchen müssen, konnte aber keins feststellen und musste die VM und die Dienste auch wieder in Betrieb nehmen)...
Es lag __NICHT__ an VirtualBox, denn die selbe Probleme habe ich auch mit VMWare.
Nun, folgendes Netzwerkkonfiguration auf dem Host:
eth0 mit IP 84.200.210.163/24 (und mehrere IPv6) eth0:0 mit IP 192.168.16.69/24 (benutzt für die Sicherung) eth0:1 mit IP 84.200.210.165/24
Auf dem Guest: eth0 mit IP 84.200.14.126/24 (und eine IPv6 im selben /64-Netz des Hosts) eth0:0 mit IP 192.168.16.12/24 (benutzt für die Sicherung)
Dazu hatte ich eine Host-Only-Schnittstelle (vbonet0 bei VirtualBox, vmnet1 bei VMWare) für die sichere Kommunikation zwischen den beiden Rechner.
Prinzipiell alles funktionsfähig. Es hat eigentlich auch funktioniert, aber sobald das Netz ein bißchen zu tun hatte (und am Ende hat es auch gereicht, wenn ich "ps axuwf" aufgerufen habe!), hat die Schnittstelle gehängt und es gab für mich keine andere Lösung, als die SSH-Schnittstelle mit kill zu beenden.
Nun, nachdem ich festgestellt habe, dass es nicht an dem Virtualisierungsprogramm liegt (denn VMWare hat dasselbe Problem wie VirtualBox) bin ich jetzt am überlegen, was der Grund des Problems sein könnte...
Mir sind diese Möglichkeiten eingefallen:
1) damit der Bridge richtig funktioniert, müssen alle IPs vom Host sowie Guest im selben Netz (und das ist nicht der Fall) 2) der Provider hat ein Problem mit den Routen, und schafft nicht die Pakete an den richtigen Schnittstelle zu schicken, sobald die eine Schnittstelle Bridge nutzt (kann nicht prüfen) 3) der Provider sperrt die Nutzung von Bridge (wie auch immer, denn ich habe ein root-Server, also ein eigenes Rechner [keine virtuelle Kiste], auf dem ich nur Zugriff habe) 4) ich habe von Bridge gar nichts verstanden und bin einfach zu blöd um sowas einzurichten
Laut lspci habe ich folgende Ethernetkarte auf dem Server:
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
ich freue mich auf eure Meinung!
Danke Luca Bertoncello (lucabert@lucabert.de)
Hallo Luca,
On Sun, Oct 09, 2016 at 08:52:04 +0200, Luca Bertoncello wrote:
Nun, folgendes Netzwerkkonfiguration auf dem Host:
eth0 mit IP 84.200.210.163/24 (und mehrere IPv6) eth0:0 mit IP 192.168.16.69/24 (benutzt für die Sicherung) eth0:1 mit IP 84.200.210.165/24
Auf dem Guest: eth0 mit IP 84.200.14.126/24 (und eine IPv6 im selben /64-Netz des Hosts) eth0:0 mit IP 192.168.16.12/24 (benutzt für die Sicherung)
Dazu hatte ich eine Host-Only-Schnittstelle (vbonet0 bei VirtualBox, vmnet1 bei VMWare) für die sichere Kommunikation zwischen den beiden Rechner.
Was hier fehlt, ist die Konfiguration der Bridge. Welche Interfaces sitzen in der Bridge? Hat die Bridge selbst eine IP-Adresse?
Prinzipiell alles funktionsfähig. Es hat eigentlich auch funktioniert, aber sobald das Netz ein bißchen zu tun hatte (und am Ende hat es auch gereicht, wenn ich "ps axuwf" aufgerufen habe!), hat die Schnittstelle gehängt und es gab für mich keine andere Lösung, als die SSH-Schnittstelle mit kill zu beenden.
Das klingt sehr nach einem MTU-Problem. Sobald der Gast ein groesseres Paket schickt (etwa die Ausgabe von "ps axuwf"), wird einem Router auf der Strecke das Paket zu gross und er schickt ein "ICMP fragmentation needed but DF set" zurueck. Wenn diese ICMP-Meldung nicht im Gast ankommt, weiss der Gast nichts davon, dass er auf diesem Pfad kleinere Pakete schicken muss. Der TCP-Layer schickt das gleiche (zu grosse) Paket noch mehrmals (retransmit) und schliesslich haegt die TCP-Verbindung.
Ein simpler Test waere, die Interface-MTU im Gast etwas zu verringern:
ip link set eth0 mtu 1400
Natuerlich das Verringern der Interface-MTU die Holzhammermethode, eigentlich sollte das oben beschriebene Path-MTU funktionieren. Um das weiter zu debuggen, muesstest Du an verschiedenen Stellen mit tcpdump sniffen, um zu sehen, bis wohin die ICMP frag needed kommen.
Nebenbei, hat vermutlich nichts mit dem Problem zu tun: Interface-Aliasing (heisst das so?), also die Verwendung von ethX:N fuer weitere IP-Adressen auf ethX sollte man nicht mehr nutzen. Besser direkt auf dem bestehenden Interface mit iproute2 weitere Adressen hinzufuegen:
ip addr add 84.200.210.163/24 dev eth0 ip addr add 192.168.16.69/24 dev eth0 ip addr add 84.200.210.165/24 dev eth0 ip -6 addr add ...
Gruss, Chris
Zitat von Christian Perle chris@linuxinfotag.de:
Hallo Christian
Was hier fehlt, ist die Konfiguration der Bridge. Welche Interfaces sitzen in der Bridge? Hat die Bridge selbst eine IP-Adresse?
Weder mit VirtualBox noch mit VMWare hatte ich die Möglichkeit was zu konfigurieren... Es gibt nur die Option "Bridge". So wie ich weiß (kann aber falsch sein!!) macht VMWare eine versteckte vmnet0, ohne IP.
Aber eine br0 mit den IPs von eth0 habe ich nicht... Meinst du, dass das das Problem ist? Ich habe mit VMWare (zumindest mit dem Player) auch keinerlei Möglichkeit eine Schnittstelle anzugeben, auf der den Bridging gemacht wird...
Das klingt sehr nach einem MTU-Problem. Sobald der Gast ein groesseres Paket schickt (etwa die Ausgabe von "ps axuwf"), wird einem Router auf der Strecke das Paket zu gross und er schickt ein "ICMP fragmentation needed but DF set" zurueck. Wenn diese ICMP-Meldung nicht im Gast ankommt, weiss der Gast nichts davon, dass er auf diesem Pfad kleinere Pakete schicken muss. Der TCP-Layer schickt das gleiche (zu grosse) Paket noch mehrmals (retransmit) und schliesslich haegt die TCP-Verbindung.
Dann wäre die Frage, warum diese ICMP-Meldung nicht den Gast erreicht...
Ein simpler Test waere, die Interface-MTU im Gast etwas zu verringern:
ip link set eth0 mtu 1400
Auf dem Gast oder auf dem Host? Ich vermute auf dem Gast, oder?
Natuerlich das Verringern der Interface-MTU die Holzhammermethode, eigentlich sollte das oben beschriebene Path-MTU funktionieren. Um das weiter zu debuggen, muesstest Du an verschiedenen Stellen mit tcpdump sniffen, um zu sehen, bis wohin die ICMP frag needed kommen.
Naja, wenn das Funktioniert, würde es mir auch reichen...
Mir ist aber eine Sache jetzt eingefallen, und zwar, ich ändere auf dem Host schon jeden Tag den MTU, damit große Dateien von dort bis zu meinen PC (der IPv6 über Tunnel nutzt!). Also, jeden Samstag (und das könnte erklären, warum Freitag alles ging, und gestern nicht mehr), wird die MTU der eth0 des Hosts auf 1400 reduziert, damit die Sicherung läuft. Am Ende, wird es wieder auf 1500 erhöht. Die Sicherung dauert aber mehrere Stunden und es hat bis zum Nachmittag gedauert...
Meinst du, dass das das Problem sein könnte? Wenn ja, könnte ich den MTU auf dem Gast auf 1300 reduzieren. Wenn die Geschwindigkeit des Gasts ins Internet etwas kleiner ist, stört mir nicht so viel, letzten Endes handelt es sich "nur" um ein Server für ICQ- und Skype-Transport für den Jabber...
Danke Luca Bertoncello (lucabert@lucabert.de)
Hallo Luca,
On Sun, Oct 09, 2016 at 09:21:34 +0000, Luca Bertoncello wrote:
Ein simpler Test waere, die Interface-MTU im Gast etwas zu verringern:
ip link set eth0 mtu 1400
Auf dem Gast oder auf dem Host? Ich vermute auf dem Gast, oder?
Auf dem Gast, hatte ich auch so beschrieben.
Mir ist aber eine Sache jetzt eingefallen, und zwar, ich ändere auf dem Host schon jeden Tag den MTU, damit große Dateien von dort bis zu meinen PC (der IPv6 über Tunnel nutzt!). Also, jeden Samstag (und das könnte erklären, warum Freitag alles ging, und gestern nicht mehr), wird die MTU der eth0 des Hosts auf 1400 reduziert, damit die Sicherung läuft.
Oha... ein wochentagsabhaengiger Netzwerkbug. Das ist schon fast was fuers fefe-Blog :-)
Am Ende, wird es wieder auf 1500 erhöht. Die Sicherung dauert aber mehrere Stunden und es hat bis zum Nachmittag gedauert...
Meinst du, dass das das Problem sein könnte? Wenn ja, könnte ich den MTU auf dem Gast auf 1300 reduzieren.
Viel kleiner als 1300 wuerde ich sie aber nicht setzen. Wenn man die Interface-MTU kleiner als 1280 setzt, schaltet der Kernel fuer dieses Interface stillschweigend IPv6 ab. Bei IPv6 ist die minimale MTU 1280.
Gruss, Chris
Zitat von Christian Perle chris@linuxinfotag.de:
Auf dem Gast oder auf dem Host? Ich vermute auf dem Gast, oder?
Auf dem Gast, hatte ich auch so beschrieben.
Ich habe es jetzt gesehen... Kennst du ein guter Optiker? :)
Oha... ein wochentagsabhaengiger Netzwerkbug. Das ist schon fast was fuers fefe-Blog :-)
Ich bin gestern fast ausgerastet... Ich lasse Freitag Abend den Server im Topzustand und Samstag früh geht nicht mehr... Ich dachte, ich werde verrückt...
Was ist übrigens den fefe-Blog?
Am Ende, wird es wieder auf 1500 erhöht. Die Sicherung dauert aber mehrere Stunden und es hat bis zum Nachmittag gedauert...
Meinst du, dass das das Problem sein könnte? Wenn ja, könnte ich den MTU auf dem Gast auf 1300 reduzieren.
Viel kleiner als 1300 wuerde ich sie aber nicht setzen. Wenn man die Interface-MTU kleiner als 1280 setzt, schaltet der Kernel fuer dieses Interface stillschweigend IPv6 ab. Bei IPv6 ist die minimale MTU 1280.
Naja, eigentlich sollte was kleiner als 1400 schon reichen, daher sogar 1399, oder? Aber ich werde mit 1300 probieren und ggfs. etwas erhöhen.
Grüße Luca Bertoncello (lucabert@lucabert.de)
Zitat von Christian Perle chris@linuxinfotag.de:
Auf dem Gast, hatte ich auch so beschrieben.
Also, das war's... Ich habe jetzt eine Test-VM auf demselben Rechner eingerichtet (gleiches Betriebssystem wie die andere). Sobald ich auf dem Host den MTU reduzieren werden die gleiche Symptome wie gestern vorkommen.
Ich habe dann den MTU auf dem Gast auf 1390 reduziert und es funktioniert alles, auch mit reduzierten MTU auf dem Host...
Auf gutem Deutsch: Christian, danke sehr! Deine Idee war die richtige!
Ich werde später die andere VM so einstellen, dass die MTU auf 1390 gesetzt wird.
Grüße Luca Bertoncello (lucabert@lucabert.de)
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Luca Bertoncello