Re: Warum Probleme mit Bridge?

[Luca Bertoncello]

Zitat von Christian Perle :


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
(lucab...@lucabert.de)

Re: Warum Probleme mit Bridge?

[Christian Perle]

Hallo Luca,

On Sun, Oct 09, 2016 at 09:21:34 +, 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
-- 
Christian Perlechris AT linuxinfotag.de
010111  http://chris.silmor.de/
101010  LinuxGuitarKitesBicyclesBeerPizzaRaytracing

Re: Warum Probleme mit Bridge?

[Luca Bertoncello]

Zitat von Christian Perle :

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
(lucab...@lucabert.de)

Warum Probleme mit Bridge?

[Luca Bertoncello]

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
(lucab...@lucabert.de)