LINBO ohne IP-Adresse (nur am L3-Switch) -- warum?

Clientpflege linbo
1

Hi.
Ich habe heute eine seltsame Beobachtung gemacht: Am Cisco-Layer-3-Switch habe ich einen Port so konfiguriert, dass ich untagged direkt auf das VLAN für den entsprechenden Raum komme. Man hängt also direkt an dem Switch, der zum linuxmuster-Server führt.

Starte ich einen Rechner, der an diesem Port hängt, erhält er via PXE seine IP – aber unter Linbo selbst hat er seltsamerweise keine (OFFLINE)! Startet man aber durch bis zur Ubuntu-GUI ist die IP wieder da.

Daraufhin habe ich den Rechner an einen anderen Layer-2-Switch gehängt, der ebenfalls das VLAN untagged an einem Port ausliefert. Dort trat das Problem nicht auf (obwohl der Weg natürlich ebenfalls über den Layer-3-Switch führt). Es war also ein Hop mehr – das Problem trat aber nicht mehr auf!

Das hatte ich in dieser Kombination noch nie. Woher kann das kommen?

2

Hallo Michael,

Ich habe heute eine seltsame Beobachtung gemacht: Am
Cisco-Layer-3-Switch habe ich einen Port so konfiguriert, dass ich
untagged direkt auf das VLAN für den entsprechenden Raum komme. Man
hängt also direkt an dem Switch, der zum linuxmuster-Server führt.

Starte ich einen Rechner, der an diesem Port hängt, erhält er via PXE
seine IP – aber unter Linbo selbst hat er seltsamerweise keine
(OFFLINE)! Startet man aber durch bis zur Ubuntu-GUI ist die IP wieder da.

für pxe und dhcp mußt du im Switch für den Port den korrekten helper
zuweisen.

Wie das geht steht in der Doku im wiki

LG

Holger

3

Hm – aber DHCP klappt ja offenbar … nur unter LINBO nicht. Sowohl PXE liefert die richtige IP als auch Ubuntu selbst. Die kommen ja in beiden Fällen per DHCP an. Mir scheint es eher an einer Wartezeit à la dhcpretry zu liegen??

4

Hallo MIchael,

ist Spanningtree auf diesem Port auf portfast gestellt bzw. deaktiviert?

vG

5

Hi.
Das wird’s sein … ich weiß, dass wir die Diskussion schon mal hatten aber in Sachen STP/RSTP blicke ich leider noch nicht ganz durch. Da ich die Settings bisher nicht angerührt habe, wundere ich mich umso mehr über die Einstellungen, die ich vorgefunden habe. Hier ein paar Screenshots. Vor allem Port 20 (root?) finde ich seltsam. Woher kann das kommen bzw wie wird das ausgehandelt? Der oben genannte Port, auf den ich zugreifen wollte, ist Port 17!

globale Einstellungen zu STP – sollten so passen?

stp1.png732×535 112 KB

STP:

stp2.png919×531 140 KB

Seltsamerweise zum Teil aktiviert und zum Teil deaktiviert. Port 20 “root” bei Portrolle. Was ist hier korrekt?

RSTP:

stp3.png919×531 133 KB

Ähnlich bei RSTP – teilweise aktiv und teilweise nicht. (Auf Port 6-9 liegt ein LAG).

Wie habt ihr das bei euch eingestellt bzw wie ist es hier richtig?

6

Hallo Michael,

ich kann dir glaube ich auch nicht weiterhelfen, außer das ich denke, dass bei Port 17 “Fast Link” Aktiviert sein sollte. Warum Port 20 “root” ist, weiß ich auch nicht. Hängt an diesem Port ein anderer Switch?

vG

7

Viele der Leitungen gehen zu weiteren Switchen … von daher ist Port 20 nicht besonders/anders als die anderen.
Aber 17 stelle ich dann mal auf Fast Link um … mal schauen, ob es hilft.

Michael

8

Hallo Michael,

man kann in der start.conf der zum PC gehörenden HW-Kklasse den Parameter dhcpretry hochsetzen/einfügen (Zeile die mit APPEND beginnt). Dann klappt das auch bei STP mit DHCP.

Viele Grüße

Peter

9

Hi.
Leider muss ich den alten Thread nochmal aufgreifen, da es heute wieder ein größeres Problem mit dem PXE-Boot und LINBO gab.

Zum Aufbau: Unser Netzwerk besteht “bauartbedingt” leider aus diversen Untervertelungen. Es sieht im Moment so aus:

Die drei Knotenpunkte bestehen aus Cisco-SG300-Switchen, von denen nur der unterste im Layer-3-Mode läuft. Alle anderen Switche drumherum sind einfache DLink DGS-1100 bzw DGS-1224. (Es ist klar, dass das nicht der aller günstigste Aufbau ist bzw dass da zum Teil viele Hops notwendig sind um an’s Ziel zu gelangen, doch das kann ich im Moment nicht ändern. Gewachsene Strukturen…)

Zum Problem:
Es scheint bei uns so zu sein, dass mit dem Upgrade auf 6.1 und der Umstellung auf Subnetting & VLANs zwei Probleme auf einmal zusammen gekommen sind: Da jetzt an allen Knotenpunkten Cisco-Switche stehen, läuft dort auch per default Spanning Tree (bzw RSTP – mit Standardeinstellungen!). Auf allen DLink-Switches ist das aber per default deaktiviert. Ich bin nach wie vor nicht ganz sicher, ob und wie man das überall einstellen muss, damit es rund läuft. Leider haben Cisco und DLink auch mal wieder unterschiedliche Namen für die gleichen Dinge, was auch schon bei der Einrichtung der VLANs manchmal für Vewirrung sorgte…

Das andere Problem ist, dass auch bei uns diverse Clients des öfteren OFFLINE starteten, obwohl sie per PXE eine gültige Adresse erhielten und auch unter Ubuntu die Adresse richtig zugewiesen wurde. Dieses Problem konnten wir aber mit der schon oft zitierten Option “dhcpretry=5” scheinbar lösen.

Eigentlich lief in den letzten Tagen damit alles sauber, doch heute Mittag ging nach einem Server-Neustart plötzlich GAR nichts mehr: In einem Raum blieben fast alle Clients direkt nach der richtig zugewiesenen Adresse per PXE stehen. LINBO zeigte nur seinen grünen Startbildschirm und das war’s. Mehr wurde nicht über’s Netzwerk übertragen. Auf den DLink-Switchen war aber wieder der Teufel los: Alle LEDs blinkten gleichzeitig regelmäßig (was bei den Dingern i.A. kein sooo gutes Zeichen ist?!)

Die Frage ist natürlich, was jetzt die Ursache sein kann: Kann das mit STP/RSTP zusammen hängen? Könnte auch eine defekte Netzwerkkarte sowas verursachen (trotz VLAN)? Man kann offenbar in viele Richtungen suchen … aber wie kann man das eingrenzen?

10

Hallo Mcihael,

Eigentlich lief in den letzten Tagen damit alles sauber, doch heute Mittag ging nach einem Server-Neustart plötzlich GAR nichts mehr: In einem Raum blieben fast alle Clients direkt nach der richtig zugewiesenen Adresse per PXE stehen. LINBO zeigte nur seinen grünen Startbildschirm und das war’s. Mehr wurde nicht über’s Netzwerk übertragen. Auf den DLink-Switchen war aber wieder der Teufel los: Alle LEDs blinkten gleichzeitig regelmäßig (was bei den Dingern i.A. kein sooo gutes Zeichen ist?!)

Die Frage ist natürlich, was jetzt die Ursache sein kann: Kann das mit STP/RSTP zusammen hängen?

… der DLINK blinkt heftig: da würde ich erstmal spontan aun einen loop
denken.
Nimm mal den DLink vom Netz und schau im „Restnetz“ ob es wieder geht.
Dann verbinde ihn wieder und schau: wenn es immer onch blinkt, dann zieh
nacheinender Netzwerkkabel, bis es aufhört zu blinken… das sollte
einen Hinweis geben.

Außerdem solltest du daran denken, dass der SG 300 einen zu kleinen MAC
Adressencache hat für Netze ab ca. 100 Cleints: das solltest du hochsetzen.

Am Ende noch ein Hinweis: ab und zu brauchen auch Switches mal einen
Reboot: also einfach mal mehrere vom Netz trennen.

LG

Holger

11

Hallo Michael,

versuche mal, mit meinen Worten ein wenig Licht ins Dunkel zu bringen:

Thema Spanning Tree

Spanning Tree ist ein Layer 2 Protokoll, das benötigt wird, um Loops im Netzwerk mit redundanten Pfaden zu vermeiden. Redundanz entsteht z.B. wenn zwei Switches 2 Uplinks besitzen, die nicht zu einer logischen Verbindung zusammengeschlossen werden. Durch Spanning Tree wird eine Verbindung blockiert und erst dann aktiviert, wenn die andere Verbindung ausfällt.

→ Habe ich keine redunanten Pfade in meinem Netz, benötige ich kein Spanning Tree Protokoll und kann Dieses deaktivieren.

→ Keine Regel ohne Ausnahme :slight_smile: Auf Cisco Switches kann es trotzdem Sinn machen, Spanning Tree zu verwenden. Sollte ein Schüler auf die Idee kommen, eine Netzwerkdose kurzzuschließen, kann dadurch auch ein Loop entstehen. Cisco bietet dazu den „BPDU Guard“ an. Dieser wird auf Portebene aktiviert. Empfängt solch ein Port jetzt sogenannte BPDU-Pakete (Spanning Tree Frames), wird Dieser automatisch deaktiviert.

Folgende Spanning Protokolle gibt es im Standard:

  • STP
  • RSTP → Weiterentwicklung von STP
  • MSTP → 1 RSTP Prozess pro VLAN (Lastverteilung im Netz möglich)

→ Ich muss mich für ein Protokoll entscheiden!

Ein Switch im Netzwerk bildet die sogenannte Root-Bridge (Switch mit der geringsten Priorität). Diese berechnet den sogenannten Spanning Tree Baum, der u.a. notwendig ist zu bestimmen, welche Uplinks zwischen Switches blockiert werden. Des Weiteren gibt es eine Backup Root Bridge (Switch der nächsten höheren Prio).

→ In unserem Fall könnte man also z.B. festlegen, dass der L3 Switch Chef werden soll, indem wir Diesem eine Prio von 4096 (Standard 32768) verpassen. Dadurch wird verhindert, dass der kleine Tischswitch Root Bridge im automatischen Verfahren (Prio + MAC) wird.

Im Spanning Tree Protokoll durchläuft ein Port verschiedene Phasen, bis er aktiv wird (Dauer 30s und länger). Da dies an Ports mit Endgeräten sehr ärgerlich ist, kann dieser Prozess verkürzt werden.

→ An Ports mit Engeräten Portfast aktivieren (STP) / Festlegen, dass es sich um einen Edge Port (RSTP) handelt …

Leider ist es oft so, dass es zwischen Switches verschiedener Hersteller Probleme mit dem Spanning Tree Prokoll geben kann. Deswegen ist es immer ratsam nach Dokumenten zu schauen, die Einstellungen vorgeben, die bei anderen Herstellern zu verwenden sind.

Die Frage ist natürlich, was jetzt die Ursache sein kann: Kann das mit
STP/RSTP zusammen hängen? Könnte auch eine defekte Netzwerkkarte sowas
verursachen (trotz VLAN)? Man kann offenbar in viele Richtungen suchen
… aber wie kann man das eingrenzen?

Ja, kann mit Spanning Tree zusammen hängen. Ja, kann eine defekte Netzwerkkarte sein, die z.B. massenhaft defekte Frames ins Netz schickt. Persönlich würde ich mit der Suche am Problemswitch beginnen:

  • Layer 1: Ports (auch der kann defekt sein), Kabel und Netzwerkkarten kontrollieren
  • Layer 2: Switchkonfig nach fehlerhaften Einstellungen auf Port- und allgemeiner (z.B. STP) Ebene durchforsten

Grüße
Bertram

12

Hm – davon steht aber bisher nichts in der Anleitung, oder? Wo finde ich das bzw welcher Wert ist empfehlenswert? Wenn man das hier liest, könnte man ja glatt auf die Idee kommen, dass der SG300 eigentlich zu klein ist für ein Schulnetz???

(letzter Satz)

Ja, ich habe es heute mal auf den Cisco-Switches deaktiviert. Leider bleibt das Problem in dem einen Computerraum bestehen. Jetzt müssen offenbar Kabel gezogen und neu gesteckt werden. Es bleibt aber dabei, dass die Probleme sehr direkt mit PXE zusammenhängen, da ja DHCP funktioniert.

13

An dieser Stelle würde ich jetzt versuchen, ein paar Fakten zu schaffen :wink:

Entweder A) den SwitchPort eines Clients am Switch spiegeln und den Traffic am Spiegelport mit tcpdump oder direkt mit WireShark aufzeichnen.

Oder B) wenn ich den Port nicht am Switch spiegeln kann, mit Hilfe eine Hubs den Traffic aufzeichnen.

Idealerweise dann die Aufzeichnung vergleichen mit einem Port, der funktioniert.

Frage: Funktioniert ein Port, der kein 802.1Q (VLAN) verwendet, d.h. ein klassischer Access Port mit einem ungetaggtem VLAN?

Vermutung: Eventuell hat es etwas mit dem Cisco Relay Agent zu tun, der eventuell nicht alles weiterleitet, was er sollte… Dafür wäre z.B. der Auswertung des Netzwerkmitschnittes hilfreich.

14

Ergänzung: Natürlich kann der tcpdump auch auf dem Server gestartet werden… Habe die Syntax nicht im Kopf, sollte aber etwa so lauten

tcpdump -nli eth0 udp port 67

oder

tcpdump -vvv -s 0 -nli eth0 port bootps
15

Das können die Cisco-Switches… weiß nur nicht mehr auswendig wo.

Alle Ports an den betroffenen Switches sind Access Ports. Da kommt NUR das VLAN für den Raum untagged an. Und es ist ja auch nicht so, dass es nicht oder NIE funktioniert. Es ist eher so, dass es nicht reproduzierbar ein paar Clients trifft, die dann direkt beim Linbo-Startbildschirm stehen bleiben.

Ja, dann müsste das aber IMMER auftauchen … und das tut es nicht. Daher die Idee, dass evlt eine NIC defelkt sein könnte. Dann tritt es nur auf, wenn der Client auch läuft??

16

Hallo Michael,

Ja, dann müsste das aber IMMER auftauchen … und das tut es nicht. Daher die Idee, dass evlt eine NIC defelkt sein könnte. Dann tritt es nur auf, wenn der Client auch läuft??

nein.
Aber: hast du das gemacht, was ich gesagt hatte?
Den Port am Switch suchen durch ausstöpseln und wieder einstöpseln: wenn
er gefunden ist: den raus lassen?

Hast du die Switches mal restartet?

LG

Holger

17

Wieso „nein“? :slight_smile:

Noch nicht … noch keine Zeit gehabt. Morgen früh evtl …

Auch noch nicht. Muss alles bis morgen warten.

Noch etwas:

Das mit dem gleichzeitigen/regelmäßigen Blinken aller LEDs ist tatsächlich NUR unter LINBO bzw PXE der Fall. Weder vorher noch nachher macht der Switch das. Es wurde ja schon vermutet, dass es evtl ein Broadcast sein kann … aber das sieht imho anders aus. SO verhält sich der Switch dann unter „normalen Umständen“ nicht, meine ich…