Netzwerkverbindung plötzlich sehr langsam

[stäubel]

Hallo zusammen

Vielleicht kann mir jemand weiterhelfen.
Ich habe ein virtuelles Linux auf einen neuen Virtual-Host transportiert.

Durch dies bekam der Rechner eine neue MAC Adresse.

Da eth0 nun verschwand und neu eth1 entstand,
konfigurierte ich die Datei /etc/network/interfaces
demensprechend neu:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth1

iface eth1 inet static
        address 192.168.0.60
        netmask 255.255.0.0
        gateway 192.168.0.1

Soweit so gut, die Webseite auf (apache2) läuft.
Jedoch ist die Netzwerkverbindung auf den Rechner nun viel schlechter.
Aufgefallen ist, dass SSH und HTTP Verbindungen sehr träge sind.

Mit tcpdump ist mir folgender Eintrag aufgefallen:

[...]
14:45:35.674301 00:10:db:8f:ff:15 (oui Unknown) > 01:10:db:f0:f0:f0 (oui Unknown), ethertype Unknown (0x8133), length 78: 
        0x0000:  0005 0104 002c 0000 0000 0000 0000 0000  .....,..........
        0x0010:  008f ff10 0000 0000 008f ff10 0000 0000  ................
        0x0020:  0000 0065 0047 9946 0000 0010 db8f ff15  ...e.G.F........
        0x0030:  0000 0110 dbf0 f0f0 0000 0410 0000 0000  ................
[...]

Kann es sein, dass die alte MAC Adresse von eth0 noch Probleme macht?

Wäre sehr froh wenn mir jemand weiterhelfen könnte.

Viele Grüsse

Stäubel

 

[x0r]

Mahltid,

... Ich habe ein virtuelles Linux auf einen neuen Virtual-Host transportiert ...

Hm, meine Glaskugel sagt mir *** ach herje, ist wohl kaputt!
Vielleicht rückst Du mit ein paar zus. Infos raus ?

Ich traue mich fast gar nicht das zu fragen, aber ein /etc/init.d/networking restart hast Du dutchgeführt ?

MfG

 

[stäubel]

Hallo x0r

Danke für deine Antwort!

Vielleicht rückst Du mit ein paar zus. Infos raus ?

Sorry für die etwas sparsame Fehlerbeschreibung.
Eigentlich versuchte ich einfach diese Meldung zu verstehen:

[...]
14:45:35.674301 00:10:db:8f:ff:15 (oui Unknown) > 01:10:db:f0:f0:f0 (oui Unknown), ethertype Unknown (0x8133), length 78: 
[...]

Virtuelle Linuxe habe ich schon oft auf neue Hosts portiert und hatte dabei
nie Probleme. Und dieses Mal war da einfach der Hund drin und ich vielleicht
etwas voreilig.

Die Fehlermeldung verstehe ich zwar noch immer nicht aber den Fehler habe
ich nun herausgefunden!! Es lag doch tatsächlich an der Verbindung, denn
über eine andere Verbindung funktionierte es nun einwandfrei.

Ich vermute fehlerhaften Switch oder Induktive-Fremdeinflüsse auf das Netzwerkkabel.
Das werde ich noch untersuchen.

Folgendes würde mich jedoch noch interessieren:

Von jeder Netzwerkkarte (ob physisch oder virtuell) merkt sich Linux
die MAC-Adresse. Wenn diese ersetzt wird, wird ein neues
Interface (ethX) erstellt.

Aber wo speichert Linux diese MAC-Adressen, wo könnte man eine MAC-ID
wieder löschen, damit z.B. das gleiche Interface verwendet wird, damit ich
nicht irgendwann bei eth1992867 bin

Danke für die Bemühungen.

Grüsse

Stäubel

 

[x0r]

Whooups, hat zwar schon ein bisserl Staub angesetzt, aber egal...

Von jeder Netzwerkkarte (ob physisch oder virtuell) merkt sich Linux
die MAC-Adresse. Wenn diese ersetzt wird, wird ein neues
Interface (ethX) erstellt.

Schon, allerdings handelt es sich dabei nicht wirklich um ein neues Interface, sondern nur um einen Schicht2-Tunnel bei dem ein Punkt-zu-Punkt Netzwerkgerät simuliert wird, das die Daten die es empfängt/sendet eben nicht über ein phys. Medium (Kabel, Luft usw.) sondern eine Anwendung des Userspace abwickelt ( si. http://de.wikipedia.org/wiki/TUN/TAP ).

Jetzt muss man wissen, das bei der Verarbeitung solche Netzwerkübertragungen der OSI-Stack für der auf einem phys. Interface aufsetzenden virtuellen Interfaces erst durchlaufen wird, NACHDEM es den OSI-Stack des phy. Interfaces durchlaufen hat.
Der Grund ist, das ein virtuelles Interface keinen Interrupt auf dem Mainboard des PCs/Servers erzeugen kann, dies wird durch das phy. Interface an der Spitze der Hirarchie abgewickelt. Der entscheidende Teil:

A virtual interface, on the other hand, has no way to receive interrupts, and thus it cannot receive any network packet. This can be perceived as unfortunate, because it would be nice to attach the same software operations to both directions of data flow. But the mechanics of packet reception don't allow virtual interface to enter the game, and whoever need to intercept incoming packets must use other ways to hook into the packets' path.

Dies kann die eine oder andere Anwendung gehöhrig durcheinander bringen,
da die Antworten der durch das virt. Interface getriggerten Schicht2-Datagramme, auf dem phys. Interface auflaufen, was je nach Kernelkonfiguration dazu führt, das die Datagramme zwar an die nächste OSI-Schicht weitergereicht, jedoch nicht verarbeitet werden, bzw. von der NIC rejected werden (kein promiscious mode ??) .

Ich vermute das es entweder virtuelle Interfaces auf dem portierten Host, oder dem Host auf den Du portiert hast gegeben haben muss.

Deswegen braucht man einen Kernelswitch, der die Kapselung der L2-Datagramme übernimmt. Hier kommt denn eben TUN ins Spiel.

Ein ähnliches Problem hatte ich mit DHCP3d und PXE-Boots in heterogenen Netzen. Hat erst funktioniert mit SW-Bridge.

Aber vielleicht *Glaskugel an* leigt das Problem ja auch gaaanz woanders *Glaskugel aus*...

MfG