Nur als Ergänzung:
Ich weiß nicht, wie gut du dein Netzwerk dokumentiert hast, aber wenn du auf Subnetting gehst, kann ich dir nur empfehlen, JEDEN Port in JEDEM Switch irgendwo zu erfassen, denn mit Subnetting ist es vorbei, mal “kurz” irgendeinen Port im Serverschrank zu benutzen und zu hoffen, dass man da 'ne IP bekommt!
Ich kann Dir eine Vorlage schicken, wenn du willst. Ich habe damals die Bilder aus dem Wiki mit LibreOffice nachgebildet und an unsere Zwecke angepasst. Dann musst du jedenfalls nicht bei 0 anfangen…
(Bei Interesse einfach per PM melden…)
Kannst du mal ein Beispiel geben wie ihr beschriftet. Also nicht das Handwerkliche sondern den Inhalt. Bin gerade am überlegen welche Informationen sinnvoll sind.
wir beschriften in der Regel bei Trunkports (die Accessports kann man sich mit show vlan ansehen, in welchem VLAN sie sind). Dort beschriften wir z.B. an welchem Port sie gehen, z.B. to_WLC_NIC1. Manchmal haben wir auch noch ein Kommentar zum VLAN oder so.
Für uns erfüllt die Beschriftung v.a. den Zweck, wenn man nicht direkt am Switch ist, aber an der Konfiguration was ändern möchte (z.B. neues VLAN) und man vergessen hat, wo der Port am Gegenüber angeschlossen ist. Ein sauberere Dokumentation würde es auch tun, aber da haben wir noch nicht die optimale Lösung gefunden, außer man macht sich eine LibreOffice Draw Dokument (haben wir auch, aber eher für die grobe Struktur, nicht für die Ports). Optioen wären evtl.
Wir haben i.d.R. die Small Business Switche von Cisco. Je nach Firmware / Modell kann man dort eine Description angeben oder man muss das “Name”-Feld dafür missbrauchen
Mir fiel auf, dass die Links auf die Konfigurationen vom L3-Switch alle auf die gleiche Datei zeigen. Das war schon vor einiger Zeit mal Thema in der Liste.
Zudem hatte ich (als wir umgstellt hatten) diese zusätzlichen Anmerkungen gemacht:
I know, dafür gibt es länger schon ein Ticket. Ich glaube, Christian @cweikl hat die Doku damals neu zusammengeschrieben. Mit Absicht oder ohne hat er ein paar Teile weggelassen. Ich habe ihn schon in github angeschrieben, mache es hiermit aber nochmal offiziell: Christian, willst du dich noch um den Rest der Doku zum Subnetting kümmern?
Will das jemand anderes machen? Hier steht wie.
Hi Tobi,
habe mit der Doku zur Netzsegmentation heute begonnen. Rückfrage: Soll denn die Doku bei den drei Segmenten bleiben ? Im Wiki ist die Darstellung komplexer mit mehr VLANs. Ich denke, es ist hilfreich, diese möglichst einfach zu halten.
VG
Chris
Hi Chris.
Also wir haben deutlich mehr als 3 VLANs. Ich habe mich damals zunächst sehr genau an die Anleitung gehalten und zunächst alles 1:1 so umgesetzt, wie es dort stand, bevor ich selbst notwendige Anpassungen vorgenommen habe. Wenn man das Schema einmal begriffen hat, läuft es für alle weiteren VLANs ja analog ab. Von daher meine ich, dass es exemplarisch mit 3 VLANs in der Doku ausreichend ist.
Zwei weitere Vorschläge zur Ergänzung (neben den schon zitierten “Fehlern” (s.o.)):
Es ist sinnvoll, ein Management-VLAN für die Verwaltung der Switches einzurichten. Bei mir ist das 10.16.2.0/24. Zugriff hat nur eine VM, die im gleichen Segment liegt. Dadurch sind die Switches etwas aus der Schusslinie genommen…
Zudem kann man mit aufnehmen, dass alle unbenutzen Ports auf ein Black-Hole-VLAN (z.B. 999) gelegt werden, damit bei fehlerhafter / unbedachter Verkabelung nichts passieren kann, was man nicht will.
ok. Deine Vorschläge zur Ergänzung sehe ich ebenfalls so - ein Management VLAN ist Pflicht ebenso eins für ungenutzte Ports (Alternative: Ports herunterfahren). Ich würde das aber zunächst in der Hauptdoku rauslassen und am Ende der Doku als Hinweis ergänzen, damit es zu Beginn möglichst einfach bleibt, oder ?
mich nervt, dass die Source-files der verschiedenen Netzwerkabbildungen immer fehlen und man denen hinterherlaufen muss. Da fängt dann jeder wieder von vorne an (z.B. für andere Sprache, v7 usw.). Im RST-Artikel ist die “dia”-Datei mit in github - vorbildlich. Schöner als die im wiki und im rST-Artikel finde ich die im Unifi-Artikel. Aber hier: keine Rückmeldung vom Autor auf meine Anfrage wg. der quelldateien und mit welcher Software das gemacht wurde.
Ja, die beiden Docs unterscheiden sich sehr in der Tiefe. Ein Dilemma: Thomas’ wikiartikel ist eindeutig zu technisch für unsere Hauptdoku. Die Doku von Frank ist deutlich reduziert, schweigt sich aber über wichtige Dinge aus.
Mir gefällt auch nicht, dass wir jetzt für die Referenz das Wikiarchiv verwenden müssen. Besser, aber aufwändig wäre die Doku von Thomas in github zu legen, wie wir es ja für “Entwickler”-Doku vorgesehen haben.
Ich schließe mich euch an: belassen wir es bei Schüler/Lehrer/Servernetz, ihr müsst (mir auch) erklären, wofür man das Managementnetz überhaupt einsetzt.
Wenn du aber bock hast: übernimm die gesamte Anleitung ins rST oder mache ein Ticket auf, dass man sie nach Markdown konvertieren und ins github stellen solle. Bis dahin: Link aufs wikiarchiv, leider.
VG, Tobias und Danke!
wenn du Zwischenergebnisse anderen (mir, Michael, usw) zeigen wolltest, ohne dass es gleich in den master-Zweig gemerged wird, könntest du im linuxmuster-docs/main Repo einen neuen branch mit aussagekräftigem Namen, z.B. „fix-95-subnetting“ aufmachen und dorthin commiten (ausgehend vom aktuellen master-Zweig natürlich).
Dann würde fast automatisch unter docs.linuxmuster.net/de/fix-95-subnetting der Branch dargestellt. Momentan muss ich oder Stephan da von Hand in readthedocs eingreifen. Wäre aber eine Möglichkeit, dass andere dein Ergebnis anschauen, solange es im fluss ist.
Hallo,
habe die Netzsegmentierung weitgehend überarbeitet, neue Config-Files für den SG300 erstellt, Infos aus ask.linuxmuster.net mit aufgenommen. Einige Abb. müssten noch überarbeitet oder manche auch neu erstellt werden. Ich habe mich dafür entschieden, doch das komplexere Szenario darzustellen, da so auch die L2-Switch Anbindung besser nachvollziehbar wird. @Tobias merge das Ganze doch bitte, damit alle das Ergebnis begutachten können.
