DHCP Request braucht sehr lang

Hallo Stephan,

in einem unserer Computerräume braucht der DHCP Request sehr lang (ca.
30s-1min) bis er am Server ankommt und dann eine IP bekommt. Wo setzt
man da am besten an, um dem Problem auf den Grund zu gehen?

Zwischen Server und Computerraum hängen 2 Gigabit-Switche. Unserer
Verkabelung ist sicher nicht die beste und ist bestimmt Teil des
Problems. Aber wie geht man am besten vor, um das Problem einzugrenzen?
Wie debugged man einen DHCP Request? Welche Alternativen gibt es zu den
recht teuren Fluke Netzwerkkabelprüfern?

Ich hatte auch schon probiert die Geschwindigkeit auf 100MBit / Full
Duplex festzusetzen, aber ohne spürbaren Erfolg.

es kann die Grundlast sein (zuviele Broadcasts) oder eine defekte
Leitung/Stecker

Es ist nur ein einziger Computerraum betroffen?
Wieviele Clients hängen dann hinter dem zweiten kaskadierten Switch?
Sind auch Clients hinter dem ersten (aber vor dem zweiten) betroffen?

Erste Anlaufstelle sollten die Logs auf den Switches sein: die führen
Statistiken, wie oft sie auf welchem Port kaputte Pakete erhalten und
erneut senden müssen: das müßte bei dir extrem auffällig sein.

Bei mir war es mal ein defektes Kabel.

Testweise könnte man auch mal ein 50m Kabel nehmen und direkt legen… am
Nachmittag, wenn keiner mehr da ist … falls 50 m reichen …

Bei dir kann es aber auch eine spanningtree Einstellung an einem der
Switches sein, oder ein Stormcontroll: dann werden Broadcasts
absichtlich ausgebremst. Schalt solche Dinge mal testweise ab in den
Switches.
Was ich auch schon hatte: seltsame Effekte im Nebengebäude: es stellte
sich heraus, dass jemand meinte: zwei sind besser als einer, und hat die
beiden Leitungen aus dem Hauptgebäude auf beiden Seiten auf die Switches
gesteckt … im Ansatz nicht schlecht, aber dann sollteman auch ein LAG
einrichten.
Ich habe eine Leitung gezogen udn schon flutschte es wieder.
An noch einer anderen Schule wurden zwei Switches im Switchschrank per
Ethernetport verbunden: auf den ersten Blick OK, aber die Switches waren
gestacked über dicke Leitungen hinten: somit war das ein Loop …

Viele Grüße

Holger

1 „Gefällt mir“

Hallo Stephan!

Alternative zu den recht teuren Netzwerkkabelprüfern:

https://wiki.ubuntuusers.de/iperf/

Aber immer daran denken, wer viel misst misst viel Mist! :wink:

Lieben Gruß

Thorsten

Hallo,

iperf › Wiki › ubuntuusers.de

Aber immer daran denken, wer viel misst misst viel Mist! :wink:

… aber der Bauer mit dem größten Misthaufen ist der wohlhabendste Bauer
… der hat nämlich die größte Herde :slight_smile:
Also: großer Haufen = gute Sache

Viele Grüße

Holger

Hallo Stephan,

vielleicht steckt irgendwo ein Loop ? Das sieht man, wenn all
Switchlämpchen wie wild flackern, oder scheinbar dauerhaft an sind.

Loops findet man indem man einen Rj45 Stecker nach dem anderen entfernt bis
das wilde Geflackere auf hört.

Gute Switches können Loops detektieren und schalten diese Ports ab, wenn
Loop-Detection eingeschaltet ist.

Gruß

Alois

:

Hallo,

erst mal vielen Dank für die ganzen Ideen zum Debuggen :thumbsup: Ich schau mir das in Ruhe an und melde mich hier wieder.

vG

Hallo Holger,

Ich habe mich heute noch mal mit dem Problem auseinandergesetzt. Nachdem fast an jedem Switch der DHCP Request so lange gedauert hat, bin ich deinem Hinweis bzgl. der Spanning Tree Einstellungen nachgegangen. Die Switche waren da noch alle in der Standardconfig, d.h. keine Prioritäten gesetzt und nur STP statt RSTP (Rapid Spanning tree) aktiviert. Dieser Artikel hat mir geholfen ein paar grundlegende Dinge einzustellen, auch wenn ich das mit STP noch nicht 100% verstanden habe:

http://www.networkworld.com/article/2223757/cisco-subnet/cisco-subnet-9-common-spanning-tree-mistakes.html

Letztendlich habe ich auf allen Access-Ports Spanning tree auf portfast gestellt und die Prioritäten und den Modus angepasst (siehe Artikel). Jetzt flutscht es wieder :slight_smile:

Danke noch mal für all die Ideen zur Problemlösung!

vG

ich bin nicht ganz sicher aber sollte man nicht bzgl LINBO in den Switches “Spanning Tree” abschalten? Nun lese ich (immer öfter), dass STP unbedingt angeschaltet sein sollte?
Kann evtl nochmal jemand sagen, was in den Switches wie konfiguriert sein sollte? Auch in Sachen IGMP etc?
Das fände ich ganz hilfreich…

Hallo Michael,

für PXE-Boot und Access-Ports im Allgemeinen sollte es “abgeschaltet” sein bzw. auf portfast. Damit entfällt die Verzögerung, die normalerweise bei STP da ist. Bei allen anderen Ports (v.a. Trunkports) würde ich es angeschaltet lassen. Für den Fall das man sich aus Versehen mal eine Loop steckt :slight_smile:

Was genau meinst du mit IGMP bzw. auf was willst du hinaus?

vG

Also wir haben (leider) viele D’Link Switche der Sorte DSG-1224 und auch DGS-1100. Die laufen zwar, kommen aber deutlich aus dem Low-Budget-Bereich und machen/nennen einige Dinge anders als z.B. Cisco.

Dort gibt es ein paar Settings, die per default disabled sind. Ich hatte das bisher auch immer so gelassen, doch nach dem was unter “9 Common Spanning Tree Mistakes” steht, sollte STP ja laufen??

Hier ein paar Screenshots der D’Link-Einstellungen:

Hallo,

sind das alle möglichen Einstellungen zu Spanning Tree? Kannst du das auch per Port einstellen?

vG

Geht unten weiter pro Port… ich hatte den Screenshot abgeschnitten…

Ok, wie gesagt, ich bin ja auch kein STP Experte. Ich denke auch, dass es in kleineren und überschaubaren Netzen kein Problem sein sollte, STP abzuschalten. Ansonsten sollte es auf allen Ports aktiviert sein, die Teil der Netzwerkinfrastruktur sind, also in der Regel Trunk-Ports. Bei Access-Ports sind die Nachteile in unserem Setting größer als die Vorteile.

vG

Bitte bei Spanning Tree die Ports auf Edge setzen, wie im Screenshot.

Da ist es wieder, das nicht eindeutig definierte Wort “trunk”. In der Cisco-Welt ist das offenbar etwas anderes als in der DLink-Welt. Was meinst du jetzt: eine Leitung, auf der mehrere VLANs sind oder ein LAG?

Ich habe die STP–Einstellungen bisher nicht geändert. Das macht doch auch nur dann Sinn, wenn man es auf allen Switches aktiviert, oder??

Ja, ein Trunkport verbindet Switche / Router miteinander und kann 1 oder mehrere VLANs transportieren. Leider weiß ich nicht, wie das in der DLINK-Welt heißt.

IMHO macht es nur Sinn, wenn es auf allen Switches aktiv ist. Dann sollte man allerdings Prioritäten festlegen (siehe oben verlinkter Artikel).

Ja, das alte Problem: “Trunk” bedeutet in der DLink-Welt ganz gerne auch “Zusammenfassen von mehreren Leitungen zu einem LAG”. Aber offenbar tanzt hier Cisco in Sachen Bezeichnung aus der Reihe und nicht die anderen? Aber egal, solange klar ist, was gemeint ist…

Und auf allen untagged Ports sollte STP also deaktiviert bleiben, ja? Warum kommt denn PXE nicht mit STP klar? Was hat beides miteinander zu tun? Mir ist der Zshg. noch nicht ganz klar…

Soweit ich verstanden habe gibt es mehrere Stadien in STP (Listening, Learning, Forwarding). Diese dauern jeweils 15 bis 30 Sekunden glaube ich. Wenn ich also jetzt meinen Rechner starte kann es ca. 45 Sekunden dauern bis der DHCP Request durchkommt, da der Port im Listening und Learning Modus AFAIK geblockt ist. Deswegen ist das für PXE / Linbo ungünstig. Es geht, aber die Boot-Zeit verlängert sich stark. STP schaut halt, ob es im Netzwerk Loops gibt und immer ein Port online geht (beim Einschalten der Rechner), dauert es eine Weile bis der „Spanning Tree“ aufgebaut ist.

Ok, dann wird auch klar, warum man das nur bei solchen Ports verwenden soll, die von Switch zu Switch verlaufen und immer an sind… aber nutzt das ernsthaft jemand, wenn es so lahm ist?? Die Hinweise unter “9 Common Spanning Tree Mistakes” klingen ja eher so, als sei das ein MUST-HAVE!??

Ja, da muss mal jmd. antworten, der mehr den Durchblick hat :slight_smile:

in der Cisco-Welt gibt es „portfast“ was STP gleich in den Forwarding-Modus versetzt. Es ist somit nicht „abgeschaltet“. Dazu gibt es noch BPDU-Guard, was im Falle des worst-case den Port abschaltet. Aber wie gesagt, ich hab vor 3 Tagen zum ersten Mal von STP gelesen :slight_smile:

Vielleicht hilft die Antwort noch weiter:

Hey,

im Kontext bitte Trunk als VLAN-Bündel ansehen ;-)…

Bei HP:
Client: spanning-tree 1-48 admin-edge-port
Server/Switch mit mehreren VLANs (Trunk): no spanning-tree 49-50 admin-edge-port

Bei D-Link eben der Edge Port für Clients, bei Trunks, einfach disablen.

Bei Cisco eben spanning-tree portfast für Ports, auf denen der mode access ist und access vlan XYZ definiert wurde.

Damit werden Ports schneller auf Forward geschaltet, damit DHCP Pakete wieder durchkommen. Während des Bootprozesses kann das ROM sowohl von BIOS, wie auch von Linbo initialisiert und angesprochen werden. Es wird dazwischen aber gerne mal kurz abgeschaltet. Clients erscheinen dann als Offline, wenn die Einstellungen nicht gesetzt sind.
Bitte auch auf smart managed Switches immer die eingebauten QoS Features abschalten (bspw. Cisco SG300 Serie).

Gruß