Probleme mit Endian und Jetway Hardware.

Hallo,

mit folgender Box haben wir aktuell massive Probleme:
http://www.jetway.com.tw/jw/barebone_view.asp?productid=1012&proname=JBC373F38-525-B%20/%20JBC373F38W-525-B

Ein Hardwaredefekt schliesse ich zunächst us, da wir mehrere dieser Boxen getestet haben.
Zum Einsatz kommt ein Endian Commuity 2.5.2.

Das aktuelle Feherbild:

Von Zeit zu Zeit friert das System einfach ein.
Trotz einer rudimenäter Überwachung war es nicht möglich eine technische Ursache oder Fehler ausfindig zu machen.
D.H. keine Überhitzung, Keine abnorme CPU Last, Keine Kernelpanik oder der gleichen.

Das System friert in der Art ein:
Keine Reaktion auf Tastatureingabe,
Pingt nicht mehr.
Keine Anzeige auf dem Monitor.
Keine Telenet Remote Konsole.

Mir sind zwar etwaige Probleme mit Realtek NICs bekannt, konnt diese aber dem Fehlerbild nicht zuornden.
Zumal, und damit begann die miesere vor ca. 6 Monaten, ein anderes Jetway System (vorgänger Board mit ebenfalls Realtek Nics) über 1 Jahre mit Endian 2.5.1 funktionsfähig online war.
Die Symthome danach waren absolut identisch. Das "Alte" System war nie wieder in einen Operativen Zustand zu bringen.
Die Ausfälle fanden in immer kürzeren Abständen statt.

Das System beleibt im wesentlichen stabil, bis Netzwerk Traffic entsteht. Alles in einem humanen bereich. 2-5 MB/s.
Heisst also, dass das Standby System die ganze Zeit online und betriebsbereit war. Just am Tag der Übernahme der Dienste, rauchte dieses exakt gleich ab.
Es ist auch weiter kein nennenswerte Last auf dem System zu erkennen.

Meine Frage ist nun, kann es wirklich sein, dass die Ursache im Netzwerktreiber des Realtek zu suche ist?
Welche Möglichkeiten habe ich am System der Ursache auf die spur zu kommen?
Welche Hardware würde sich hier am besten eignen.

AHCI und ACPI wurden deaktiviert.
SSD wurde wieder gegen ein nornale SATA Platte getauscht,
RAM auf Fehler geprüft. -> negativ alles i.O.

Hi,
wie schon gesagt, wir verwenden mehrere dieser Boxen.

Insgesamt jeweils 4.

1. aus Redundanzgründen
2. Weil man verschiedene Dinge trennen musste.

Der genannte Typ ist neu. Das Problem tritt aber auf allen auf. Demnach müssten ja auch auf allen 4 das Netzteil defekt sein.
Das Problem tritt aber erst auf, wenn das System ein bischen Last in form von Netzwerktraffik erhält.

Als das Problem begann, waren noch andere Jetway Boards im Einsatz.
Ebenfalls 4 Stück und das Problem konnte ebenfalls auf allen 4en reproduziert werden.
Kann es wirklich sein, dass ein treiberproblem eine solche verherende Wirkung hat?

Da ich leider keine Brauchbare Entwicklerumgebung bekomme, bin ich auch nicht in der Lage ein Kernel Modul für endian zu schaffen um das aus zu probieren.
http://unixblogger.wordpress.com/2011/10/18/the…-ethernet-card/

-> Allerdings baue ich mir eine Box mit Centos4 auf und versuche es eben damit. Lediglich u das Fehlerbild zu reproduzieren und ggf. nach zu weisen, dass es daran liegt.
Über tips wie ich dennoch eine saubere Endian Entwicklungsumgebung auf bauen könnte, wäre ich sehr dankbar.

Mich ärgert es auf jeden Fall, weil wir seit über einem 1/2 Jahr Endian nicht mehr zum laufen bekommen.
Schlussendlich auch für mich ein Grund langfristig von Endian auf eine alternative Lösung zum zu steigen.

Zitat von "redhat"

Das Netzteil hat passend Spannung und bringt auch die entsprechende Leistung?
Kenn das von anderen Geräten,tut man nix ist alles gut,kommt Last auf. bricht das System zusammen.

Hi, ich habe es gerade schon gepostet wollte aber noch konkreter dazu ein gehen.
Die Netzteile werden vom Hersteller auch geliefert.
Im Labor haben wir versucht das Fehlerbild nach zu stellen und auch eine thermisches problem aus zu schliessen.
Weder ein ausführlicher Benchmark noch über 3 TB geroutetet Traffic konnten das Problem rekunstruieren.
-> Zuhause aber auch im RZ sind nun die gleichen Netzgeräte im Einssatz. Ich halte es erstmal für ausgeschlssen dass es daran liegt, zumal das Gerät ja nicht aus ist, sondern wirklich einfriert.
Nics und HDD LED blinken ja.

Danach das System wieder eingesetzt.
Ein wenig Taffic drüber und Sie schmiert ab.
Im 2. Schrritt bin ich dazu über gegangen, habe die IP Tables Regeln extrahiert und auf einem anderen OS eingespielt.
Vermutung war, ob es ggf. eine geziehlte Schwachstelle der FW gibt und diese Missbraucht würde.
So, und jetzt kommt der Knaller.

Nachdem wir die IP Tables Regeln eingespielt haben, mussten lediglich -state durch conntrack und ctstate tauschen, passierte genau das gleiche auf dem neuen OS.
Das mag nun ein blöder Zufalle gewesen sein (Immer noch Treiber Problem), oder es stimmt etwas grundlegendes an den Regeln nicht?

Soweit zumindest zum Stand von heute. Ich tappe nch im dunkeln.
Vor ab schon mal Danke für die Denkanstösse.

Mmmmh, die Switche sind im wesentlichen auch identisch.

Auf dem roen Netz hängt das System an einem Netgear günstiger 1Gbit Desktop Switch gs 108 bzw. das andere Gerät an einem anderen Switch (Nachfolger von GS 108).
Das grüne Netz hingegen war an einem Netgear netgear GS 748T angebunden.

Zur Netzwerktopologie:

Das System im Rz ist redundant angebunden.
also redundane Netzwerkanbindung vom Carrier.

Das geht getrennt auf unterschiedliche Switche und von dort an die Firewallsysteme.
Ab dem Firewallsystem geht es wieder auf getrennte Netzwerkinfrastruktur (GS748T) und im Cluster betriebene Server.
Laut dem Switch sind keine Fehler oder dergleichen aufgefallen.
Diese Teststrecke ohne Redundanz hatten wir so aufgebaut.

Ich bin aktuell leider nicht in der Lage den Netzwerktraffik auf zu zeichnen und exakt so im Labor nochmals ab zu spielen.
Daher haben wir nur den bekannten Traffik (sync vom repository) nach gestellt.
Ich werde es auch ersmtal nicht schaffen, die Switche zu tauschen.
Im Grunde kann man aber sagen, dass die 4 Firewallsystem in der kompletten Strecke autark in einer eigenen Netzwerkinfrastruktur eingebunden sind.
Es bestehen auch keine Brücken wodurch dieses z.B. verschleppt werden würde. Bestünde also nur noch die Ursache Netzwerkseitig beim Carrier zu suchen, da hier das Netz zusammen läuft.

Im Grunde sieht es so aus:

Carrier
LAN1..........................................LAN2
...|.................................................|
GS108....................................2. GS 208
...|.................................................|
Gateway1/2...........................Gateway2/4
....| ............ |................................|............|
Switch1--Switch2..................... SW3.......SW4
....| ............ |................................|............|
Server1..Server2......................Server3...Server4

Die Punkte dienen nur als Trenzeichen.

Früher war es etwas anders aufebaut aber seit der Störung entsprechend getrennt.

Hi,

also wie Du es der Zeichnun entnehmen kannst, handelt es sich allein im grüne Netz Segment um 2 GS748 Switche, 2 GS 102 Switche (wobei hier nur dei 2 gibt).
Natürlich noch die 4 Gateway Systeme elche an unterschiedlichen Prtos am Switch stecken.

Letzte Woche, als wir mal wieder eine Störung hatten entschlossen wir uns spontan das Netzwerk neu zu verkabeln.
Es herrschte ein gwisser Kabelsalat. Bei der Aktion wurden auch die Gateways an einen anderen Port angeschlossen.

Meine Vermutung lag darin, dass es eventuell eine softwareupdate gegeben haben könnte.
Aber ein älteres ISO Image der 2.5.1er Version habe ich aktuell nicht vorrätig um das zu verifizieren.

Nochmals kurz zur Historie:

Vor rund 6 Monaten trat das problem mit unseren alten boxen (Nicht die oben verlinkte) auf.
JNC92-330-LF + AD3TLANG-LF
Da wir hier eine SSD einsetzen, lag die Vermutung nahe, dass ggf. diese ein Problem hat.
Ein Tausch der Platte durch eine herkömmliche, änderte daran nichts.

Wir erstelleten ein komplett anderes System, (auch ein Jetway Board andere CPU, anderer RAM vermutlich aber auch mit Realtek NICs).
JNC9C-550-LF + J2AD3RTLANG
Diese hatten ein eigenständiges Gehäuse.

-> Das Problem blieb.
Jetzt haben wir die oben genannte Box im Einsatz mit Upgrade auf Endian 2.5.2.
Gleiches Problem.

Die Ports wurden geswitcht. also die Boxen neu verkabelt.
Auch die GS108 Switche wurden ausgetauscht hatte aber einen andere Grund. Machten den Durchsatz nicht mehr mit.
Aber das alles hat die Ursache nicht beseitigt.
Und wie schon gesagt im Labor haben wir bestmöglichst eine identische Umgebung aufgebaut.

Mal einfach eine Frage in den Raum:

Bestünde die Möglichkeit eine Endian ATM Mercury und Macro X ausführlich zu testen?
Könnte einer der ggf. hier anwesenden Partner etwas bewegen? Wir benötigen später aus redundanz Gründen und dem Wunsch diese als Cluster zu betreiben 2 Stück.
Aber zunächst möchte ich sehen, dass das auch funktioniert.

2. Und das ärgert uns immer noch bis aufs Blut, wir wollen keine "Merchandising in 12 Monaten nicht mehr updatefhähige" Lösung!
Das ist auch der Grund, warum wir eine Endian ATM Lösung als solche nicht mehr in erwägung gezogen haben.
Die 1. Box welche uns mal in einer "Promo" verkauft wurde, hatte angeblich 5 Jahre Support auf Hardware und Software.
Nach 6 Monaten kam die Version 2.5.1 raus und wir wollten updaten. Seitens Endian hiess es, dass diese Hardware nicht mehr unterstützt würde.

Wir planen einen einsatz über min 3 Jahre und in diesem Zeitraum erwaten wir auch eine nutzbarkeit inkl. Upgrade Möglichkeit.
Uns bringen versprochene 5 Jahre Support nichts, wenn der Hersteller die Hardware nach 12 Monaten nicht mehr supportet.

Er hat schon eine PN geschickt kommt ja aus Ulm, vielleicht reicht es mir heute noch dort vorbei zu fahren.

Hallo,

was die Hardware betrifft bin ich schon mal weiter.
Zumindest konnte ich einen entsprechenden Fall Rekonstruiren.
In dmesg finde ich folgendes:

[   47.019848] warning: `ntpd' uses 32-bit capabilities (legacy support in use)
[   47.791260] br1: no IPv6 routers present
[   47.843267] br0: no IPv6 routers present
[   47.887267] br2: no IPv6 routers present
[   47.924266] eth10: no IPv6 routers present
[   47.986261] eth9: no IPv6 routers present
[   48.171263] eth7: no IPv6 routers present
[   56.350298] device br0 entered promiscuous mode
[   56.414303] device br1 entered promiscuous mode
[   56.490287] device br2 entered promiscuous mode
[ 1352.998548] i2c /dev entries driver
[ 3889.170675] r8169: eth7: link up
[ 3889.199840] r8169: eth7: link up
[ 3889.203549] r8169: eth7: link up
[ 3900.858818] r8169: eth7: link up
[ 3906.153687] r8169: eth7: link up
[ 3906.157790] r8169: eth7: link up
[ 3917.329380] r8169: eth7: link up
[ 3917.334475] r8169: eth7: link up
[ 3921.737959] r8169: eth7: link up
[ 3921.742209] r8169: eth7: link up
[ 3931.579621] r8169: eth7: link up
[ 3939.247835] r8169: eth7: link up
[ 3939.251456] r8169: eth7: link up
[ 3948.734997] r8169: eth7: link up
[ 3948.743179] r8169: eth7: link up
[ 3953.283765] r8169: eth7: link up
[ 3965.236401] r8169: eth7: link up
[ 3965.240236] r8169: eth7: link up
[ 3968.722338] r8169: eth7: link up
[ 3968.726171] r8169: eth7: link up

eth7 ist das grüne Netzwerk.
Das ganze passierte, als ich rund 10GB generiert aus /dev/null geroutet über das Netzwerk per scp kopieren wollte.
Das ging eine ganze Weile gut, dann flog das Interface. Kein Ping nichts.
Das lässt sich so auf allen anderen Boxen absolut identisch rekonstruieren.

Das passiert jedoch nur, wenn ich netzübergreifend, also aus dem roten Netz ins grüne oder andere Richtung, die Daten schiebe.
Versuche ich es nur lokal von der Endian auf einen Endpoint klappt es nicht.
Ganz schön krank. Aber es kommt noch besser.
Geroutet bekomme ich einen Datendurchsatz von rund 40-50 MB hin.
Von der Endian bis zum Endpoint aber nur max. 11MB/s .

Ich versuche jetzt doch mal auf einer Box eine Sophos Lösung zu instalieren und auf einer andere ggf. die Entwicklungsumgebung von Endian soweit zum laufen zu bekommen, das ich mir ggf. den Treiber selber bauen kann.

Ich bin mit dem Fehlerbild etwas weiter.

Rekonstruiert habe ich folgenden Fall:
Zum Einsatz kam ein bestehendes altes Jetway Board mit 2,13 GHz Intel CPU, 2 Realtek onboard NICs und einer 3 Ort Erweiterungskarte mit Intel NICs.

So lange der Traffic nicht über eines der Realtek Interfaces geht besteht kein Problem.
Wird aber der Realtek Adapter genutzt, fällt genau das Interface innerhalb kürzester Zeit aus.
Das traurige, den Fall bekommen wir so nur im RZ rekonstruiert. Offensichtlich liegt es an der Gibt Anbindung.
Denn am 100;bit Netz lässt sich der Fall nicht rekonstruieren.
Der Anwendungsfall ist einfach nur ein per rsync initiierter Download / Abgleich mit einem online Repository.
Durchschnittlich werden ca. 25-30 MB/s übertragen.

Jetzt stelle ich mir natürlich die Frage, wo bekommt man einen passenden Treiber her? Ich habe es nicht geschafft das Ganze zu bauen.