Zeitüberschreitung der Anforderung

[-hannes- 10]

Hallo,

 

 

ich habe in unserem Netzwerk ein Problem mit dem ping auf bestimmte Server.

 

Die Umgebung ist relativ simpel, außer was die LWL-Leitungen zwischen den Verteileren betrifft.

 

Es gibt 4 Verteiler, von denen 3 per LWL im Single-Modus über D-Link DGS-1210-24 Switche verbunden sind. Ein Verteiler ist zum Hauptserverraum über je 1x Cisco Catalyst per LWL ebenfalls im Single-Modus angebunden.

 

Außer den D-Link DGS-1210-24, die eigentlich viel zu klein sind, gibt es sowohl an den einzelnen Verteilern, als auch im Haupt-Server-Raum noch zahlreiche ältere D-Link Switche verschiedenster Modellreihen und auch Switche anderer Hersteller, die dann alle mit Kupfer untereinander verbunden sind.

 

Die Server laufen auf VMware vSphere mit ESX-Server 4.0 im HA-Modus, d. h. es sind 2x ESX inkl. Infrastructure-Server vorhanden.

 

Wenn ich nun z. B. den DC pinge ist alles in Bester Ordnung. Pinge ich aber einen bestimmten anderen Server, habe ich nach ca. 20 pings immer eine "Zeitüberschreitung der Anforderung", was aufgrund der zeitkritischen Anwendung, die dort läuft, eigentlich nicht zu vertreten ist.

 

Firewall ist aus. Netzwerkeinstellungen der Karte und DNS sollten passen.

 

Einzigstes Problem seit einem Stromausfall durch den Netzbetreiber ist, dass der ESX1 einen Fehler beim HA meldet, wo er angibt "Das Management Netzwerk wäre nicht redundant aufgebaut", falls das hier mit rein spielen kann. In den Weihnachtsferien ist hier mal ein Reboot im Wartungsmodus geplant um das zu beheben.

 

Meine Frage deshalb:

 

nach was kann ich suchen oder z. B. mit Wireshark capturen, um den Grund für die Zeitüberschreitung beim pingen herauszufinden?

 

Problem ist nämlich, dass sich das ganze derzeit öfters mal "aufschaukelt" und dann eben mehr als eine Zeitüberschreitung hintereinander auftritt, so dass die Clientanwendungen den Dienst quittieren, die auf den Server zugreifen.

 

Mein persönlicher Ansatz ist, dass die Infrastruktur aus den unzähligen Switchen einfach zu verworren ist und es auf dem Weg durch die zahllosen Switche zu Kollisionen kommt, so dass Pakete verworfen werden.

 

Dies leitet mich direkt zu meiner zweiten Frage über:

 

Hat jemand damit Erfahrung die D-Link DGS-1210 in einer Art "quasi" Stack-Modus zu betreiben z. B. über V-LANs? Wie müsste das aussehen?

 

Ich würde dann nämlich die Kraut-und-Rüben-Landschaft mal bereinigen und einfach pro Verteiler und beim Haupt-Server 2-3 Stk. von den 48-Port-Modellen Anschaffen und diese per LWL untereinander verbinden. Dabei müsste aber gewährleistet sein, dass die Switche praktisch nach außen hin wie z. B. ein großer 96-Port arbeiten, aber gleichzeitig es bei den Verbindungen zu den anderen Verteileren über ebenfalls LWL zu keinen "Schleifen" kommt, wofür unsere Infrastruktur momentan ohnehin extrem anfällig ist. Wie wäre hier ein V-LAN umzusetzen?

 

Kann bitte jemand helfen? Ich hab`s nämlich langsam echt satt ständig an irgendwelchen einzelnen Ports herum zur flickschustern :cry:

 

Vielen Dank,

hannes

bearbeitet 14. Dezember 2010 von [hannes]
beim D-Link DGS-1210 kein echter Stack-Modus laut Datenblatt

[zahni 554]

Hm, Aus Deiner Beschreibung werde ich leider nicht schlau.

 

Eventuell hast Du einen Loop gebaut:

 

Preventing network loops with Spanning-Tree Protocol (STP) 802.1d

 

Mit Wireshark kommt Du da leider nicht weiter bzw. müsstest Du Dich in die Uplink-Ports einschleifen.

 

Die HA-Konfig vom ESX ist auch etwas heikel. Dazu fehlen Informationen.

Den HA-Agenten kann man normalerweise auch im Betrieb neu installieren.

 

-Zahni

[-hannes- 10]

Hallo,

 

die Geschichte mit dem Loop habe ich natürlich bedacht und deshalb ist RSTP auch eingeschalten, was aber das Problem beim pingen nicht gelöst hat.

 

Sich bei LWL in die Uplink-Ports einzuschleifen dürfte wohl aufgrund fehlender Netzwerkkarten eher schwieriger bis unmöglich werden.

 

Gibt`s denn stattdessen gar keine Möglichkeiten? Irgendwelche "Hausmittel", die man mal abarbeiten sollte, wie z. B. den TCP/IP Stack zu resetten, oder etwas in der Art?

 

Wegen dem HA-Problem, hier eine genauere Beschreibung:

 

1.) Konfigurationsprobleme: "Der Host ESX02 verfügt momentan über keine Verwaltungsnetzwerkredundanz" (Fehler auf Registerkarte "Übersicht" bei markiertem Knoten HA in der Baumstruktur links des vCenter Server)

 

2.) Konfigurationsprobleme: "Der HA-Agent auf ESX01 in Cluster ha_01 im Datencenter Fimenname hat einen Fehler: Zeitüberschreitung bei der Kommunikation mit dem HA-Agenten. (Fehler auf Registerkarte "Übersicht" bei markiertem Server ESX01 direkt unterhalb des Knotens HA ind der Baumstruktur links des vCenter Server)

 

Wird es jetzt etwas deutlicher? Beide ESX Server haben je 3 NICs mit 2 Ports, wovon je 1 NIC für das Verwaltungsnetzwerk bestimmt ist. Die so insgeamt 12 Ports hängen alle per Kupfer an dem selben Switch.

 

Bin sehr daran interessiert, das Problem im Laufenden Betrieb zu lösen, da dies sicher viel weniger fehleranfällig ist als mein erster Vorschlag.

 

Vielen Dank.

hannes

[Cybquest 36]

Könntest du da mal ein Bild malen und irgendwo hochladen?

Geschrieben klingts irgendwie wirr...

Die Switche sind mit Single-Mode LWLs verbunden? Sind auch Single-Mode GBics in den Switchen?

Wireshark o.ä. an einem Uplink ginge ja auch, wenn der Switch den Uplink auf einen normalen, freien Port mirroren kann (ob das bei DLink geht, weißich nicht). Dann kannst mit normalem Kupfer per Laptop z.B. messen.

[-hannes- 10]

oh, sorry.

 

wollte natürlich keine Verwirrung stiften.

 

Bei den LWL-Verbindungen kommt auch Multi-Mode, statt Single-Mode zum Einsazt. War gestern Abend schon leicht hinüber.

 

GBICs sind auch in den D-Links vorhanden. Aber ob sich die auf Kupfer spiegeln lassen, wage ich mal zu bezweifeln, weild das Kombo-Ports sind, d. h. wenn einer von den 4 äußersten LWL-Ports mit einem GBIC belegt ist, kann man den korrespondierenden Kupfer-Port nicht belegen. Das auszuprobieren gestaltet sich auch heikel, da mir sonst im Fehlerfall das Produktivnetz wegbricht ... Aber die Idee ist natürlich Gold wert :) Werde ich auf jeden Fall zusätzlich im Auge behalten.

 

Bild mach` ich gleich. Dauert sicher etwas ...

 

Gruß,

hannes

[Cybquest 36]

Hab grad mal nach dem DLink gegoogelt. Der kann wohl Port-Mirroring:

ftp://ftp.dlink.de/dgs/dgs-1210-48/documentation/DGS-1210_man_revA_1-00_all_en_20100107.pdf

 

Wg. Multi-/Monomode ist halt wichtig, dass das Kabel und der GBic zusammenpassen.

 

Viel Erfolg.

[-hannes- 10]

So, ich stell fest, dass ich für Visio 2010 entschieden zu wenig Shapes habe ;)

 

 

 

 

Link: Bild: verteiler-uebersichtjg53.jpg - abload.de

 

Der Aufbau ist natürlich stark vereinfacht. Pro Verteiler gibt es wie o. g. noch zahlreiche verschiedene Switche, da hier die Ports sonst nicht ausreichen. Spielt es für die Performance und RSTP eine Rolle, ob diese untereinander verbunden sind, oder sollte jeder separat 1x an dem Switch mit dem GBIC-Modul von D-Link angeschlossen sein?

 

Jeder ESX ist 6x per Kupfer an den "Haupt-Switch" im Server-Raum angebunden.

 

Wie sollte der Aufbau optimal gelöst werden?

 

Danke,

hannes

[-hannes- 10]

... ich stelle fest, dass ich für Visio 2010 eindeutig zu wenig Shapes habe.

 

Aber ich denke den Grundaufbau kann man gut erkennen:

 

 

Link zum Bild: http://h-3.abload.de/img/verteiler-uebersichtjg53.jpg

 

An den Verteilern gibt es, wie bereits eingangs erwähnt, noch zahlreiche andere Switche, da sonst die Ports nicht ausreichen. Spielt es für die Performance und RSTP eine Rolle, ob die zusätzlichen Switche untereinander, anstatt jeweils 1x direkt mit dem D-Link der den GBIC hat, verbunden sind?

 

Die ESX-Server sind per Kupfer je 6x mit dem "Haupt-Switch" im Serverraum verbunden.

 

Wie sollte eine saubere Konfiguration am besten aufgebaut werden?

 

Vielen Dank,

hannes

[Cybquest 36]

Sieht doch unspektakulär aus.

Besser wärs schon, wenn die vielen zusätzlichen Switche direkt an den jeweiligen Switch mit dem LWL-Uplink gehen, wenn 2 oder 3 aber hintereinander hängen, weils nicht anders geht, sollte es dennoch nicht zu Problemen kommen. Ungeschickt wirds wohl, wenn die untereinander auch noch irgendwie verbunden sind und dann noch welche dabei sind, die z.B. kein RSTP können.

 

Wenn die ESXe, die da Linkprobleme melden, alle auf einem Switch landen (oer auf dem "Switchverbund"?!?), würde ich dennoch eher ein Problem direkt am Switch vermuten...

[zahni 554]

Und paost mal Screenshots der vSwitch-Konfig und der HA-Konfig

[hegl 10]

Ich kenne die Problematik mit defekten GBics. Was sagt denn die Portstatistic, hast du da irgendwelche Fehler (FCS-Error, CRC-Error)?

[-hannes- 10]

@Cybquest: Deine Empfehlung deckt sich hier völlig mit meiner geplanten Wunschkonfiguration. Vielen Dank für die Bestätigung. Jetzt fehlt nur noch die bestellte Hardware ...

 

@zahni: nachfolgend erstmal, was ich momentan an Screenshots von gestern noch im Posteingang habe. Morgen mach' ich noch ein paar von den Konfigs. Hier sieht man aber jetzt schon mal die beschriebenen Fehler.

Interne Firmennamen musste ich aufgrund von Vorgaben unkenntlich machen.

 

@hegl: Danke für den Tipp. Das war auch mein erster Blick. Aber Fehler werden auf den GBIC Ports absolut keine gemeldet. 0,00 Fehler. Nichts. Der Port an dem der derzeit noch IPcop Router angeschlossen ist meldete allerdings 'ne Zeit lang ziemlich viele Fehler. Nachdem der Port am Switch dediziert auf Router umgestellt wurde, passts derzeit eigentlich auch da.

Nach neuen Fehlern kann ich dann morgen noch mal schauen. Worauf deuten FCS-Error und CRC-Error jeweils? Lässt sich hieraus was direkt ableiten?

 

So, hier die Screenshots:

 

 

 

 

Vielen Dank,

hannes

[-hannes- 10]

... hier noch die weiteren Screenshots von der Netzwerkkonfiguration und der vSwitche:

 

ESX01 Netzwerkadapter:

 

 

ESX01 vSwitch:

 

Teil 1:

 

Teil2:

 

 

 

ESX02 Netzwerkadapter:

 

 

ESX02 vSwitch:

 

 

 

Wäre nett, wenn noch mal jemand drüber schauen könnte. Vielleicht steckt der Wurm ja auch hier irgendwo drin?

 

Vielen Dank,

hannes

[hegl 10]

@hegl: Worauf deuten FCS-Error und CRC-Error jeweils?

 

 

Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues - Cisco Systems

[-hannes- 10]

Das ist ja mal wirklich eine äußerst spannende Lektüre !!

 

Wie`s aussieht sollte ich wohl auch mal auf NIC Ebene forschen.

 

Vielleicht funkt z. B. einfach die Nagios Dienstüberwachung dazwischen, indem sie bestimmte TCP/IP Eigenschaften der NICs umkonfiguriert hat? Das NSTray Tool von Nagios produziert jedenfalls oft Windows-Fehler.

 

Ebenfalls sehr spannend ist die Tatsache, daß eine Konfiguration von Auto am NIC und Force-Mode am Switch nicht wirklich zu empfehlen ist und Duplex Fehler produzieren kann.

 

...da wartet im nächsten Jahr aber noch ziemlich viel Arbeit, bis das Netz wirklich 100% stabil läuft.

 

Vielen Dank hegl, für den wirklich informativen Link :)

 

hannes