Re: AW: hängendes Netzwerk
Hallo miteinander, Kurz zusammengefasst die Erkenntnisse, die letztlich mein Problem gelöst haben. 1. Status jetzt: bond0 Link encap:Ethernet Hardware Adresse 00:15:17:DD:DE:22 inet Adresse:172.16.0.20 Bcast:172.16.255.255 Maske:255.255.0.0 inet6 Adresse: fe80::215:17ff:fedd:de22/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:193552957 errors:0 dropped:10 overruns:0 frame:0 TX packets:85113290 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:209304300835 (199608.1 Mb) TX bytes:6416975258 (6119.7 Mb) Die 10 dropped packets stammen vermutlich aus der Initialisierungphase am Switch, denn die verteilen sich gleichmäßig auf eth0-eth3 (wobei eth1 keine Pakete gedropt hat, denn dieses Interface wird vom Treiber als erstes initialisiert, die Nummerierung ändert UDEV). Das Problem bestand am Switch selbst, den die Netzwerkfirma eingerichtet hat. Der Switch muss natürlich die Bündelung der Netzwerkkarten seinerseits richtig unterstützen. Dazu dient LACP, um per 802.3ad zu bündeln. Nun begab es sich, dass jene Firma zwar einen wilden Wuchs an Kabeln in den Switch führte, jedoch nirgends etwas dokumentierte. So war weder an den Kabeln, noch an Farben o.ä. ersichtlich, was wohin führte. Als ordnungsliebender Mensch davon gefrustet, entschied ich mich, die Kabel neu zu stecken, mit Aufklebern zu versehen und die Portbelegung des Switch sauber zu dokumentieren (OO-Tabelle). Laut der Beschreibung von HP ist LACP normalerweise bei Server-Einschüben (VL-Modul mit LWL-Anschlüssen) per AUTO aktiviert. Bündelung wird damit automatisch erkannt und vom Switch unterstützt. An anderen Anschlüssen kann es zudem aktiviert werden. Nun hatte jene Firma an einigen Ports dieses LACP aber deaktiviert. Eth2 und eth3 steckten also auf Ports, die somit nicht mehr automatisch gebündelt wurden. Da sie aber von UDEV und dem Bonding-Kerneltreiber gebündelt wurden, sendete der Switch die an anderen Port gesendeten Pakete wieder zurück - und wurden korrekt abgewiesen (also dropped). Dummerweise kommt man an diese Einstellungen nicht per Web-Interface heran, nur per Telnet oder serieller Konsole. Dadurch ist der Fehler erst so spät aufgefallen. Bist Du sicher, dass Dir da so etwas wie UDEV nicht reinfunkt? Ich habe mich gerade auf mehreren Systemen mit Intel Multiportkarten umgesehen, dort haben alle Schnittstellen immer eigene MAC. Auch dass kann ich erklären: Wiederum mit dem Switch. Die Netzwerkkarten, die jetzt ohne Aktivierung in das Bonding mit einer IP versehen wurden, steckten auf Ports, die LACP nicht auf Auto, sondern auch AKTIV stehen hatten. Damit bündelte der Switch irgendwie diese Karten und entweder Kernel-Treiber oder UDEV (oder beide?) erkannten offenbar diese erzwungene Bündelung. Nachdem ich einen Port umgesteckt hatte, bekamen die beiden Interfaces korrekt verschiedene MAC-Adressen verpasst (die natürlich aufeinander folgten). Fazit: Trau keiner Netzwerkfirma, die nicht einen Ordner mit Dokumentation übergeben hat. Hinterher sucht man sich dumm und dämlich... Gruss Reiner ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
AW: hängendes Netzwerk
Hallo Reiner, Bist Du sicher, dass Dir da so etwas wie UDEV nicht reinfunkt? Ich habe mich gerade auf mehreren Systemen mit Intel Multiportkarten umgesehen, dort haben alle Schnittstellen immer eigene MAC. Leider war bei meinen Referenzen eben nicht genau Dein Modell dabei, aber ich höre von sowas zum ersten Mal. Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Triebischtal www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Reiner Klaproth klapr...@online.de (So 04 Dez 2011 08:34:02 CET): Hallo! Am Samstag, 3. Dezember 2011, 18:00:53 schrieb Reiner Klaproth: Einen Reboot später weiß ich mehr: Jetzt zählt nicht mehr der Zähler an eth3 hoch, sondern der an eth2 (Weiß der Fuchs warum...) Auch das ist erklärbar: Die Netzwerkkarten sind Intel-Serverkarten, die mit einem Baustein zwei Netzwerk-Interfaces anbieten. Somit sind also eth2 und eth3 physisch an einen Baustein gekoppelt (und haben dieselbe MAC-Adresse!). Gebündelt oder als Hub betrieben… wobei ich bei Serverkarten eher ersteres vermute, wiewohl ich das noch nie gesehen habe. Vielleicht kann man das in irgend einem BIOS beeinflussen. Denn intuitiv kommt mir das nicht vor. Wenn ich an einem Server zwei Ports sehe, dann würde ich auch davon ausgehen, daß ich zwei Ports (NICs habe). Bist Du Dir sicher, daß die Dinger schon vor dem „enslaven“ in das Bond-Interface die selbe MAC haben? Daher hatte der Kernel das Problem, die Karten zuzuordnen. Darin steckt offenbar auch das Problem: Laut lspci haben diese Karten keinen Interrupt zugeteilt bekommen. Das ACPI-Management liefert als IRQ 66 und 76. Da sehe ich keinen Zusammenhang zur selben MAC. Fakt ist offenbar, dass Intel die Karten selbst auch als Bündel betreibt. Offenbar schaltet nicht nur eth3 auf 100MBit herunter, sondern parallel auch eth2. Das erklärt die verlorenen Pakete. Ach so, eth3 und eth2 sind ja nicht gemeinsam im Bond-Interface. Dann ist meine Frage von oben vielleicht auch Quatsch. Das gleich der Chip beide Interfaces „runterzieht“, wenn man die Geschwindigkeit auf einem ändert, ist ja eine dolle Sache. Erster Würg-Around: Nur noch eth0 und eth1 sind auf bond0 gebündelt, denn diese funktionieren (auch eine Intel-Dual-Port-Serverkarte). Wahrscheinlich muss der Server eine weitere Netzwerkkarte erhalten für das 100MBit-Interface. Schön, dass so etwas nirgends ordentlich dokumentiert ist... Nun schon ☺ -- Heiko signature.asc Description: Digital signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
hängendes Netzwerk
Hallo allerseits! Ich brauche mal Nachhilfe bzw. Tipps bei folgendem Problem: Erkennbar ist, dass an einem Linux-Server mit Samba 3.5.7 (SuSE 11.4) manchmal keine Anmeldung möglich ist, ein andermal das Profil nicht geladen wird und man damit kaum arbeiten kann. Problem 1 ist gefunden: Die Nutzerprofile hatte ich auf eine zweite Festplatte ausgelagert. Diese SATA-Festplatte ist aber gegenüber dem SAS-Raid schneckenlahm (etwa 80MB/s gegenüber 240MB/s) und bremst damit bei paralleler Anmeldung mehrerer Schüler natürlich aus. Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen? Der zweite Teil des Problems liegt in dropped packets auf den Netzwerkkarten. Es kann sein, dass ich hier ein Verständnisproblem habe. Daher etwas ausführlicher zum Netzwerkaufbau: Es gibt 4 Netzwerk-Interfaces (Intel 1000er-Karten). Aus technischen Gründen ist ein Interface (eth3) auf 100MBit gedrosselt und landet am Switch auf einem getrennten VLAN (Wiederherstellung vom Laptops mit 100MBit-Karte per Multicast-Netzwerk). Die Interfaces eth0-eth2 sind gebündelt, das Netzwerkinterface ist also bond0. Was auffällt: Die Zahl der dropped packet von eth3 und bond0 stimmt (fast) überein (unterscheiden sich um genau 100), beide wachsen im exakt gleichen Maß. An den realen Interfaces eth0-eth2 gibt es keine dropped-Pakete, der angezeigte Durchsatz ist völlig in Ordnung. Zwischen eth3 und bond0 ist natürlich ein forward-Regel eingebaut. Auf der Firewall ist laut iptables -L keine Regel mit DROP. Die SuSE-Firewall ist aus, eine manuelle Regel sorgt dafür, dass zwei sezielle Rechner Samba-Zugriffe mit Reject beantwortet bekommen (ist notwendig). Frage 2: Warum gibt überhaupt ca. 1% Netzwerkpakete bei dropped? Wo werden die möglicherweise gedropped? Gibt es einen Grund, warum eth3 und bond0 fast identische Zahlen dabei haben? um nicht zu sehr zu raten die Zahlen von bond0: -- schnipp RX packets:73486162 errors:0 dropped:19165992 overruns:0 frame:0 TX packets:71049331 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:54676801251 (52143.8 Mb) TX bytes:68091939812 (64937.5 Mb) -- schnapp Bin für jede gute Idee dankbar Reiner ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Am 03.12.2011, 10:34 Uhr, schrieb Reiner Klaproth klapr...@online.de: Hallo Reiner, snip Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen? d.h. Du willst dafür bestehende Partitionen verkleinern? Ist nur 'offline' vorgesehen - siehe z.B. http://wiki.ubuntuusers.de/Dateisystemgröße_ändern Nutzt Du LVM? Grüße, Bernhard ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Hallo Rainer,
Reiner Klaproth klapr...@online.de (Sa 03 Dez 2011 10:34:34 CET):
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der
Server läuft (aber niemand angemeldet ist), um Platz für eine weitere
Partition zu schaffen?
Ungefährlich. Denn es geht nicht. Du kannst ext{3,4} nur offline
resizen, aber dann ist es ungefährlich, wenn man rechnen kann.
Der zweite Teil des Problems liegt in dropped packets auf den Netzwerkkarten.
Es kann sein, dass ich hier ein Verständnisproblem habe. Daher etwas
ausführlicher zum Netzwerkaufbau:
Es gibt 4 Netzwerk-Interfaces (Intel 1000er-Karten).
Aus technischen Gründen ist ein Interface (eth3) auf 100MBit gedrosselt und
landet am Switch auf einem getrennten VLAN (Wiederherstellung vom Laptops
mit 100MBit-Karte per Multicast-Netzwerk).
Die Interfaces eth0-eth2 sind gebündelt, das Netzwerkinterface ist also bond0.
Was auffällt: Die Zahl der dropped packet von eth3 und bond0 stimmt (fast)
überein (unterscheiden sich um genau 100), beide wachsen im exakt gleichen
Maß.
An den realen Interfaces eth0-eth2 gibt es keine dropped-Pakete, der
angezeigte Durchsatz ist völlig in Ordnung.
Wie oft wird das eth3 gebraucht? Wenn ich den Zweck oben richtig
verstehe, dann ja eher selten, oder?
Zwischen eth3 und bond0 ist natürlich ein forward-Regel eingebaut.
Auf der Firewall ist laut iptables -L keine Regel mit DROP. Die SuSE-Firewall
ist aus, eine manuelle Regel sorgt dafür, dass zwei sezielle Rechner
Samba-Zugriffe mit Reject beantwortet bekommen (ist notwendig).
DROP in der Firewall hat mit dropped der Netzkarte m.E. nichts zu tun.
Die dropped in der NIC könnten Empfängerüberläufe sein.
Frage 2: Warum gibt überhaupt ca. 1% Netzwerkpakete bei dropped?
Wo werden die möglicherweise gedropped? Gibt es einen Grund, warum
eth3 und bond0 fast identische Zahlen dabei haben?
Das ist merkwürdig. Gibt es Traffic, der mit beiden Karten etwas zu tun
hat. VLANs machen auch manchmal komische Dinge. Ist das ein 802.1q VLAN?
Wie ist gebondet: Als Bündel und alle gemeinsam, oder wie? Ich denke, es
gibt ja da verschiedene Bond-Modi.
--
Heiko
signature.asc
Description: Digital signature
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Hallo! Am Samstag, 3. Dezember 2011, 12:07:44 schrieb Bernhard Bittner: Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen? d.h. Du willst dafür bestehende Partitionen verkleinern? Ist nur 'offline' vorgesehen Bereits erledigt. Dienste stoppen - umount /home - gparted nutzen und machen lassen. Die Partition wurde ohne Datenverlust verkleinert, die neue Partition für die Profile eingerichtet. /etc/fstab anpassen und neu booten. Die Frage bezog sich vor allem darauf, dass ich alles per ssh machen muss, ohne die zwei Tage physisch an den Server zu kommen. Gruss Reiner ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Hallo!
Am Samstag, 3. Dezember 2011, 16:01:48 schrieb Heiko Schlittermann:
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der
Server läuft (aber niemand angemeldet ist), um Platz für eine weitere
Partition zu schaffen?
Ungefährlich. Denn es geht nicht. Du kannst ext{3,4} nur offline
resizen, aber dann ist es ungefährlich, wenn man rechnen kann.
Richtig, habe ich nur falsch beschrieben. Man muss die Partition umounten,
dann geht alles.
Die Interfaces eth0-eth2 sind gebündelt, das Netzwerkinterface ist also
bond0. Was auffällt: Die Zahl der dropped packet von eth3 und bond0
stimmt (fast) überein (unterscheiden sich um genau 100), beide wachsen
im exakt gleichen Maß.
An den realen Interfaces eth0-eth2 gibt es keine dropped-Pakete, der
angezeigte Durchsatz ist völlig in Ordnung.
Wie oft wird das eth3 gebraucht? Wenn ich den Zweck oben richtig
verstehe, dann ja eher selten, oder?
Jaein. Neben den Laptops, die sonst per WLAN am Netz hängen gibt
es noch LCD-Bildschirme mit integriertem Computer, die auch über dieses
Interface gehen müssen.
Witzigerweise haben die Gigabit-Netzwerkkarten, aber die PXE-Software für
diese Karten kann nur 100MBit (hat mich damals Tage gekostet, das
herauszufinden...)
Einen Reboot später weiß ich mehr:
Jetzt zählt nicht mehr der Zähler an eth3 hoch, sondern der an eth2
(Weiß der Fuchs warum...)
Jetzt verstehe ich aber die Zahlen: An eth2, das zu bond0 gebündelt ist,
verschwinden RX-Pakete.
Die Frage, die ich jetzt klären muss: Warum verschwinden die Pakete und
warum ausschließlich an eth2.
Die andere Frage: Warum zeigte das ifconfig erst an eth3 statt eth2?
Kernel SuSE-default zu OpenSuSE 11.4
Wie ist gebondet: Als Bündel und alle gemeinsam, oder wie? Ich denke, es
gibt ja da verschiedene Bond-Modi.
Richtig. Ich hatte einige Anleitungen gelesen und vieles getestet. Am Ende
hat es erst funktioniert, wenn man NICHTS vorher eingestellt hat und
die Intel-Karten hat machen lassen. In dem Fall haben sich die Karten mit
dem (HP ProCurve) Switch selbst geeinigt. Der schaltete seinerseits
die Eingänge zum Bündel automatisch zusammen, wenn man keine
Parameter angegeben hat.
Mit Parameter gab es Probleme mal am Switch, mal mit den Karten
Gruss
Reiner
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Am 03.12.2011, 18:00 Uhr, schrieb Reiner Klaproth klapr...@online.de:
Servus,
Am Samstag, 3. Dezember 2011, 16:01:48 schrieb Heiko Schlittermann:
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn
der
Server läuft (aber niemand angemeldet ist), um Platz für eine weitere
Partition zu schaffen?
Ungefährlich. Denn es geht nicht. Du kannst ext{3,4} nur offline
resizen, aber dann ist es ungefährlich, wenn man rechnen kann.
Richtig, habe ich nur falsch beschrieben. Man muss die Partition
umounten,
dann geht alles.
ja, wenn man eine Partition zur Verfügung hat, die umounten im laufenden
System mitmacht, geht es latürnich so wie Du es geschrieben hast.
Abgesehen von Kandidaten wie eben /home, ggf. noch /opt oder /srv hörts
dann aber m.W. schon auf.
Nicht daß noch jemand durch 'es geht nicht' - 'dann geht alles' verwirrt
wird ;-)
Seit ich mit nem ähnlichen Szenario zu tun hatte, bin ich begeisterter
Nutzer von LVM (an dieser Stelle props an Dimitri Puzin, der mich da
rangeführt hat :-).
Grüße,
Bernhard
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: hängendes Netzwerk
Hallo! Am Samstag, 3. Dezember 2011, 18:00:53 schrieb Reiner Klaproth: Einen Reboot später weiß ich mehr: Jetzt zählt nicht mehr der Zähler an eth3 hoch, sondern der an eth2 (Weiß der Fuchs warum...) Auch das ist erklärbar: Die Netzwerkkarten sind Intel-Serverkarten, die mit einem Baustein zwei Netzwerk-Interfaces anbieten. Somit sind also eth2 und eth3 physisch an einen Baustein gekoppelt (und haben dieselbe MAC-Adresse!). Daher hatte der Kernel das Problem, die Karten zuzuordnen. Darin steckt offenbar auch das Problem: Laut lspci haben diese Karten keinen Interrupt zugeteilt bekommen. Das ACPI-Management liefert als IRQ 66 und 76. Fakt ist offenbar, dass Intel die Karten selbst auch als Bündel betreibt. Offenbar schaltet nicht nur eth3 auf 100MBit herunter, sondern parallel auch eth2. Das erklärt die verlorenen Pakete. Erster Würg-Around: Nur noch eth0 und eth1 sind auf bond0 gebündelt, denn diese funktionieren (auch eine Intel-Dual-Port-Serverkarte). Wahrscheinlich muss der Server eine weitere Netzwerkkarte erhalten für das 100MBit-Interface. Schön, dass so etwas nirgends ordentlich dokumentiert ist... Gruss Reiner ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
