Netzwerk Dokumentation

[WASABJ]

Hallo Forum,

bei meinem neuen Arbeitgeber wird bis dato Dokumentation eher klein geschrieben. Bald wird unser Netzwerk komplett erneuert. Da möchte ich von Anfang an eine Vernünftige Dokumentation einführen. Mit welchen Tools erstellt Ihr eure Netzwerk Dokumentationen??? Welche Infos sind notwendig (Sinnvoll).

thx

WASABJ

[emrich]

Welche Infos sind notwendig ?

Damit theoretisch ein externer der das System nicht kennt, in dem System arbeiten könnte.

Also wird beispielsweise folgende Informationen benötigt:

- IP-Adressen von Router, Firewall, Switche, Server, Drucker und weitere Netzwerk Gerätschaften

- Physische Server oder VMs ?

- Administrator Benutzer/Passwörter

- Beschriftungen von Patchfelder/Netzwerkdosen

- Wo liegen die Datensicherungen & welche liegen dort ?

Weitere Ideen können auch aus dem "IT-Notfallplan Thread" genommen werden

http://www.fachinformatiker.de/security/157336-erstellung-it-notfallplans.html

Bearbeitet 30. November 2013 von emrich

[WASABJ]

Danke für die Antwort.

Aber mit welchen Programm wird normalerweise so ein Plan erstellt?? Visio?? Allerdings weis ich nicht ob Visio das vernünftig darstellen kann bei einer gewissen Größe (20 Server, 200 Clients, 40 Drucker)???

thx

WASABJ

[Smau]

Visio. Du kannst mehrere Sheets parallel verwenden. (z.B. ein Sheet pro Switch)

[Crash2001]

Im Visio-Plan werden im Normalfall nicht alle Server eingezeichnet, sondern nur die Netze, an denen die Server hängen. Meist gibt es dafür dedizierte Server-Switche, oder aber sie hängen direkt am Core- oder Distribution-Switch mit dran. In kleineren Firmen ist es aber halt auch schon mal so, dass sie an den normalen Access-Switches hängen (in großen Firmen wird dies aus Performance- und Redundanzgründen meist nicht so gemacht).

Du hast also z.B. einen Hauptswitch ( = Core ), an dem mehrere "Unterverteilerswitche" ( = Distribution ) hängen. Dort solltest du jeweils die IP-Adressen eintragen, die die Switche haben (Verwaltung, Layer3-Verbindungen, VPN, ...). Zudem gehört der Name des Switches dazu und möglichst auch noch, wo er steht (falls das aus dem Namen nicht ersichtlich ist). Zusätzlich gehört dann noch dazu, ob die Leitung ein Trunk ist, oder nur ein bestimmtes vlan darübergeführt wird. Natürlich gehören auch Portbezeichnungen dazu.

Routingtabellen gehören ebenfalls in eine Netzwerkdoku.

Wichtig ist auch, dass die entsprechenden Server, die Netzwerkdienste zur Verfügung stellen (DHCP, DNS, PXE-Boot, TACACS, Radius, ...) bekannt sind, damit man weiß, wo sie jeweils dran hängen. Ob man das nun im Netzplan mit einzeichnet, oder in der beschreibenden Doku des Netzwerkes hinterlegt, ist eigentlich egal. es muss nur halt irgendwo stehen.

Falls ein Etherchannel gebildet wird, gehört dies auch in die Doku (also einfach einen Kreis um die Leitungen machen, die miteinander einen Channel bilden und dann noch das Protokoll vermerken, das sie sprechen, wie z.B. LACP und dazu möglichst auch noch der Modus (static, active, passive))

Wenn per HSRP/VRRP/GLBP Interface angelegt werden, kann man diese auch noch mit angeben - wenn sie immer an gleicher Stelle liegen (also z.B. immer auf dem Core-Switch), dann braucht man dies nicht im Netzplan machen. Zumindest in der ausformulierten Doku sollte es aber erwähnt werden - und vor allem auch die Einstellungen (also z.B. wer standardmässig Master / active ist, welche Priorität die Gerätejeweils haben, u.s.w.)

Ebenfalls gehört in die ausformulierte Doku, welche weiteren Techniken eingesetzt werden und mit welchen Einstellungen (STP/RSTP/MST/..., Storm Control, BPDU-Guard, Root-Guard, Port-Security, Filterlisten, IP-Helper Adressen, dynamsiche Routingprotokolle und statische Routen, Defaultroute, Zugangsbeschränkungen, Passwörter wenn das Authentifizierungssystem ausfällt, SNMP/RMON-Zugangsdaten, welche Tools was monitoren, VPN-Tunnel/-Zugänge, MPLS-Sachen, (M)GRE-Tunnel, Zertifikate, WLAN-Verschlüsselung und SSID / Passwort, sonstige Anbidungen an andere Netze (DSL, Kundenanbindungen, Verbindungen zwischen Standorten, ...)

Dabei muss man nicht immer alles in einen Plan packen, sondern man kann z.B. auch einen Unterplan für die Serverlandschaft erstellen oder für die globalen Anbindungen, oder aber fürs Rechenzentrum selber eventuell auch noch mit allen Ports, die dann im Hauptplan nicht auftauchen, damit es übersichtlicher und nicht zu überladen wird. es hat vor allem nicht jede Firma den Luxus, dass sie auf Din A0 ausdrucken kann (was für Netzwerkpläne sehr sinnvoll ist).

Genauso kann bei mehreren Gebäuden z.B. auch jeweils ein Gebäudeplan erstellt werden (eigentlich nur sinnvoll, wenn dort auch eine Unterverteilung mit Switchen ist und nicht nur die reinen Access-Switche ( = Enduser-Switche ) dort stehen.

Zur Doku gehört dann eigentlich auch die aktuelle (regelmässig aktualisierte) Config aller Netzwerkgeräte.

Natürlich gehören in die Doku auch die Firewallregeln oder -grundlagen aufgrund derer Regeln vergeben werden (z.B. alles von aussen erst einmal verbieten, alles was von intern kommt, darf nur ins Internet für surfen, sonst aber nichts bis auf Ausnahmen, Verkehr von netz x nach Netz y ist gar nicht erlaubt, ...)

Ebenfalls in die Doku gehören Softwarestände und welche Geräte zusammen im Cluster (bzw. VSS oder ähnliche Techniken) arbeiten.

Das war es dann erst einmal für den reinen Netzwerkteil - dazu kommt dann natürlich noch der Serverteil mit den Diensten, Sicherheitsrichtlinien, Konfigurationen, ...

@Smau:

Also auf den Switch runtergebrochen finde ich z.B. bei reinen Access-Switchen nciht unbedingt sinnvoll, wenn man anhand der verkabelung erkennen kann, wo der Port hingeht, bzw. eine entsprechend aussagekräftige Description (z.B. Dosenbezeichnung) in der Config hinterlegt ist.

Für die Verkabelung zwischen Core- Distri- und Serverswitchen macht es natürlich Sinn, da sich dort nicht dauernd etwas ändert (Stichwort Userumzüge).

Sinnvoll kann zudem (zumindest falls 19"-Schränke verwendet werden) z.B. auch sein, dass man Schrank(reihen)ansichten macht, also wo man jeweils welchen Switch im Schrank findet. Kann ganz hilfreich sein, wenn man mal per Telefon einem Techniker sagen soll, welcher Switch getauscht werden soll, o.ä. ...

Bearbeitet 2. Dezember 2013 von Crash2001

[tester2k5]

Tools zur Dokumentationen können je nach Umfang der Dokumentation und Anzahl der mitwirkenden Kollegen von Word und Excel, Wiki, OneNote, SharePoint, bis hin zu speziellen Dokumentations-Applikationen wie z.B. i-doit (nicht getestet) reichen.

Mögliche Tools zum Sammeln von Informationen im Netzwerk (abhängig von der größe des Netzwerks):

• SYDI (Computer)
  
• The Dude (Server)
  
• LAN Topolog (Switche)
  
• FING (Network Scanner)
  
• DumpSec (Network Shares)
  
• SoftPerfect Network Scanner
  
• BgInfo (Computer Inventory via Database Feature)
  
• Lan-Secure Switch Center (Network Discovery and Mapping)
  
• HP ProCurve Manager (Switch Discovery, Management and Drawing)
  

Gruss,

tester2k5

[ardcore]

Also Passwörter/Zugangsdaten in ein Dokumentationsfile ala Visio, Word, PDF o.ä. zu schreiben halte ich für unverantwortlich. Auch Routingtabellen gehören in keine Doku. Und ob jetzt in eine Netzwerkdoku alle x-tausend Clients eingetragen werden sollen, die Frage sollte sich auch von selber erübrigen.

[Crash2001]

Also Routingtabellen gehören imho schon in eine Doku. Willst du etwa bei Problemen (z.B. irgendwer hat aus Versehen eine Route gelöscht oder dachte sie würde nciht mehr benötigt) denn nachvollziehen können, wohin es geroutet wurde?

In einem kleinen Netz ist es meist auf Anhieb klar, wohin geroutet werden muss und welche Route, aber in einem konzernweiten Umfeld hat man da keine Chance ansonsten oder muss sich die Infos mühsam zusammensuchen in den Configs.

Klar trägt auch eine Configsicherung (so dass man die Routingkonfiguration nachschauen kann) dazu bei, aber einen Auszug der Routingtabelle zu haben kann halt manchmal echt hilfreich sein.

Passwörter / Zugangsdaten gehören entweder in einen Passwortsafe, oder aber in ein verschlüsseltes File.

Clients werden in einem Netzwerkplan nicht eingetragen (solange sie nicht irgendwelche Sonderaufgaben haben und wichtig sind, wie z.B. zur erstellung von Freischaltungen fürs WLAN oder so oder zur Zeiterfassung), sondern höchstens Server. Dafür dann aber eher eine separate Doku, wo dann auch die jeweiligen Switchports angegeben werden. Bei mehreren Serverräumen halt pro Serverraum.

Clients in einer Datenbank inklusive Switchport aufzunehmen kann sinnvoll sein zu Debuggingzwecken. Entsprechende Tools dafür gibt es ja diverse (meist so eine Art Helpdesktools).

[gewünschter_Benutzername]

Gut ich habe meine für Zuhause in Word gezeichnet was super funktioniert hat.

Klar eignet sich nur für ein kleines Netzwerk mit <30 Clients.

[Thanks-and-Goodbye]

Gut ich habe meine für Zuhause in Word gezeichnet was super funktioniert hat.

Wenn es wenigstens ein Visio-Shape gewesen wäre... aber Word zur grafischen Netzwerkdoku?

[gewünschter_Benutzername]

Möglich ist es mit den Linien und Box module. Einfach ne Textbox erstellen das wichtigste reinschreiben und mit 2 Linien verbinden.

Fertig. Klar für paar Pcs ist das schnell und einfach gemacht. Kann als PDF exportiert werden oder gedruckt und erfüllt den Zwech schnell und einfach.

[eneR]

In einem kleinen Netz ist es meist auf Anhieb klar, wohin geroutet werden muss und welche Route, aber in einem konzernweiten Umfeld hat man da keine Chance ansonsten oder muss sich die Infos mühsam zusammensuchen in den Configs.

In einem konzernweiten Umfeld sollte man wohl ein Config Management Tool nutzen welches, wohl in Verbindung mit einem ACS, loggt wer welche Änderungen wann durchgeführt hat etc.. oder?

[Crash2001]

@eneR:

Hätte, wäre, wenn .... wenn das entsprechende Tool nicht mehr erreicht werden kann, weil eine Route fehlt, bringt einem das genau NULL.

Genau aus dem Grund sollte man halt auch einen Auszug der Routingtabelle haben.

Alternativ hilft natürlich die Config weiter - da muss man aber dann erst einmal wissen, wer mit wem über welches Protokoll spricht, wer der aktive Router mit der besten Route standardmässig sein sollte, etc... mittels eines Auszugs aus der Routingtabelle (im Normalzustand, wenn alle Router ereicht werden können) ist man da doch teilweise um einiges schneller

[ardcore]

Um nochmal den Punkt der "Routingtabellen in einer Netzwerkdokumentation" aufzufassen: Sie können situativ rein oder sind total fehl am Platz.

Bei kleinen Unternehmen mit 2-3 Routern sicherlich machbar, wenn da 1-2 Seiten Routingtabellen stehen, die sich zudem nicht oft ändern, denkbar und sinnvoll.

Bei großen Unternehmen die Crash2001 angesprochen hat, absolut nicht handelbar und unnütz. Wie bekannt, sind Routingtabellen eine perspektivische Ansicht des Routers auf das Netzwerk, dass zudem temporalen Veränderungen unterliegt. Will heissen, bei grossen Netzwerken ist die Sicht (Routingtabelle) an unterschiedlichen Stellen im Netz mit Sicherheit zu großen Teilen unterschiedlich. Zusätzlich, wie der Name es schon impliziert, unterliegt dynamisches Routing Schwankungen. Dh. aktive Routingpfade schwenken, auf Grund von Uhrzeiten, Netzauslastungen, Paketlaufzeiten, Loadbalancing, Wartungsarbeiten, Inaktivitäten, Umbauten, Netzausfällen mit unter stark. Teilweise haben Router in grösseren Konzernen weit über 10.000 interne Routingeinträge. Bei ~ 50-60 Zeilen pro Seite sind das alleine 200 Seiten Routingtabellen pro Router. Auch über 1000 Router sind keine Seltenheit. Sprich wir reden hier mal schnell über mehrere zehntausend DIN-A4-Seiten an Routinginformationen, die ständiger Veränderung unterliegen. Von externen Routinginformationen die benötigt werden, haben wir noch gar nicht gesprochen. Wenn nun jemand diese Informationen in eine Netzwerkdoku mit aufnehmen würde, ich glaube ich würde mir ernsthafte Sorgen um seinen geistigen Verfassungszustand machen.

Fazit:

Kleine Unternehmen mit überschaubarem Routingumfang und Netzgrösse: good to have.

Grosse Unternehmen mit weitläufigem Routingumfeld: useless.

[Crash2001]

Ja gut, ich meinte jetzt auch nicht weitweit operierende Konzerne, sondern eher KMUs oder "kleine Konzerne" mit noch überschaubaren Netzen.

Zudem gibt es verschiedene Stellen wo Routen notwendig sind und das meiste läuft über die Defaultroute zum "Hauptrouter des Standortes".

Je nach Routingkonzept erhält man halt unterschiedlich detaillierte Informationen.

Werden VRFs eingesetzt, so sollte man zumindest die Routen den entsprechenden VRFs zuweisen können. Ob nun anhand der Routingtabelle für das jeweilige VRF, oder anhand von anderen Dokumenten.

[Meise :)]

Moin zusammen,

ich versuche es mal hier, weil ich glaube dass mein Problem ähnlich ist...

Ich bin auch auf der Suche nach einem Tool, mit dessen Hilfe ich eine Architektur abbilden kann, zusätzlich muss es aber mehrere optional es aber diverse (Software) Layer darstellen können, mit dessen Hilfe die Leute später geschult werden sollen.

Die Idee dahinter ist, dass der Weg der Software und Anfragen eines kleinen Tools über die Architektur gelegt werden kann um eine Fehleranalyse machen zu können.

Bisher bin ich hier nur auf Dia gestoßen (Dia zeichnet Diagramme gratis - Open Source Programm für Windows, Mac OS X und Linux), das wirkt schon ziemlich optimal. Aber für Hinweise bin ich immer dankbar

[gewünschter_Benutzername]

hey

zb mit netscan kannst du das netzwerk vermessen.

hast du mal in wikipedia geschaut da gab es auch viele software hinweise.

[Meise :)]

Hi,

bei Wikipedia habe ich noch nicht geschaut.

Mir geht es tatsächlich auch weniger um die Architektur in Richtung der IP Adressen (wird alles über Services gesteuert), sondern mehr ein Aufzeigen der Wege der Anfragen. Grob kann man das bestimmt auch in Excel abbilden, aber da es rund 60 Arbeitspakete mit verschiedenen GUIs sind, inkl. einer Kundendatenverarbeitung und einem angebundenen System (ca 250 SSTs), das eine parallele Verarbeitung fährt würde das wohl nur zur Verwirrung beitragen...

[Network2014]

Also wir verwenden Visio. Auf www. visiocafe.com kannst du dir Shapes deiner originalen Geräte herunterladen. Somit kann man auf den ersten Blick sehen wie dein Netzwerk verkabelt ist. Nötige Informationen die auf der Dokumentation stehen sollten wären für mich eig. nur die Portnummern der Verbindungen.

Wenn du Rechnerarbeitsplätze, Drucker usw. Dokumentieren möchtest würde ich hierfür ein Excelsheet verwenden. Dort trägst du anhand einer Tabelle einfach Switch, Portnummer, Patchfeldnummer, Enddevice und gegebenfalls Speed, Duplex und VLAN mit ein.

Gruß Network2014

[Meise :)]

Hi Network,

ich denke am Ende des Tages hast du Recht, und ich werde das so machen. Leider habe ich Visio nur in der Firma und bin nicht unbedingt gewillt mir das für den Privatbereich zu kaufen, darum bin ich zu Dia gewechselt.

Mein Problem ist außerdem, dass es Visio für MAC noch nicht gibt

Aber ich denke dann muss ich mich halt immer aufloggen.

Danke für eure Hilfe

Gruß

Björn

[Crash2001]

Ansonsten schau mal hier.

Da werden einige Alternativen (auch für MAC) genannt.