Wie legt ihr Patchfelder und ihre Verbindungen an?

Heckmann

Hallo,

bin gerade beim Verbindungen erstellen wollte meine Patchfelder jetzt mit dem Switch und dem Gerät bzw. Netzwerkbuchse verbinden, aber er kann ja nur pro Port eine Verbindung zulassen.

Wie habt ihr das gelöst?

Gruß
Tim

ds

Hi,
es gibt momentan leider noch keine entsprechende Kategorie für Patchfelder, du kannst dir zwar einen Objekttypen anlegen, aber die Verbindung nur von Patchfeld-Port zu NIC-Port abbilden und nichtmehr die weitere Verbindung dahinter.
Wir arbeiten aber dran!

_Chekov_

Hallo zusammen,

erst die folgende Thread nachschauen:
http://www.i-doit.org/forum/index.php/topic,739.0.html

Die Patchpanele muss man selbst definieren, die sind nicht Standard Bausteine von
i-doit.

Im Praxis die Verbindungskette sieht folgendermaßen aus:

[network switch @ rack #3] <-> [patchpanel #2 @ rack #2] <-> [patchpanel #1 @ rack #1] <-> [server #1 @ rack #1]

kurze erklärung:

Die beide, Server #1 und das erste Patchpanel #1 sind im Rack #1 drin.
Patchpanel #2 kann man ja verstehen als gegenstück für Patchpanel #1. Patchpanel #2 ist im Rack #2 drin und man findet
viele weitere Patchpanele von Rack #2. Rack #2 man versteht als "connectivity schnittstelle".
Rack #3 ist voll mit Netzwerk Hardware, wie zum Beispiel Modulare Switches, Routers usw.

Jetzt kleben wir die Bausteine zusammen und das heisst wir müssen:

Netzwerk -> Port -> 2x Ports einrichten

Ganz genau! Das bedeutet das man richtet für 24-Port Patchpanel insgesamt 48 einzelne Port einträge, zum Beispiel:

Port 01
Port 01-
Port 02
Port 02-
Port 03
Port 03-
Port 04
Port 04-
…
usw. bis
Port 24
Port 24-

Port 01 ist CAT5/Ethernet Schnittstelle Vorderseite von Patchpanel #1 und verbunden mit Server #1 Netzwerk Interface #1 was als eth0 bezeichnet wurden.
Port 01- ist Rückseite von Patchpanel #1 und ist verbunden mit Patchpanel #2 und deren Port 01- was man von die Rückseite findet.
Patchpanel #2 und deren Port 01 (Vorderseite) ist nun verbunden mit 48-Port Network Switch @ Rack #3 und ist angeschlossen auf Port #18.

Jetzt sind wir mit den Verbindungskette durch und die Verbindungen zwischen Server und Network Switch ist jetzt besser nachvollziehen.

Cheers,

Chekov

ds

Kann man so machen, allerdings weiss dann nur das menschliche Auge welcher Eingangsport zu welchem Ausgangsport gehoert. Heisst man kann zum Beispiel keine Reports wie "Zeig mir mal den Verbindungsweg von meinem Client zum Switch" darüber laufen lassen
Für eine reine Dokumentation ist dieser Weg aber durchaus praktikabel

_Chekov_

Hast du aber Falsch verstanden:

Port 01 ist Vorderseite der Patchpanel
Port 01- ist Rückseite der Patchpanel

alles von anfang bis ende nachvollziehbar, aber man muss erst die allen schnitstellen
einrichten und verbunden mit die Ports.

Cheers,

Chekov

ds

Ja, nachvollziehbar für den Menschen der draufguckt, das Programm weiss aber nicht was davon deine Vorder- und was deine Rückseite ist

_Chekov_

Dann los mit implementierung, bitte.

Das ist meiner "Workaround" so lange es keine andere Lösung gibt.

Ja da hast du recht, nur die blöden Maschinen wissen halt nichts davon
wie die Patchpanele wurden konfiguriert, aber ich habe für unseren bedarf
es festgelegt das jeder wer mit den i-doit arbeiten soll muss das auch wissen
wie die Patchpanele bei uns wurden konfiguriert:

Port 01 ist Vorderseite
Port 01- ist Rückseite.

Problem ist dadurch relativ elegant gelöst.

Cheers,

Chekov

Heckmann

Der Ansatz von Master -Chekov ist recht gut und werde es jetzt auch so umsetzen.
Wenn dann das Update kommt. Schreibe ich es um(sind bei mir zum Glück nur ca. 30 Ports)

Sadmin

Hey, hätte ich vielleicht zuerst lesen sollen, dann hätte ich mir den Beitrag hier: http://www.i-doit.org/forum/index.php/topic,496.msg3802.html#msg3802 ersparen können.

perkelenz

So, jetzt muss ich mal fragen wie weit denn die Entwicklung diesbezüglich ist.
Weil genau an diesem Thema hänge ich gerade … und ich habe nicht nur 30 Ports abzubilden

jocki

Wir sind am Thema dran und wollen bis spätestens Mitte Juni eine Funktionsbeschreibung posten. Anhand der diskutiert werden soll, ob das dahinter stehende Modell die Anforderungen soweit abdecken kann.

jela

@jocki:

Wir sind am Thema dran und wollen bis spätestens Mitte Juni eine Funktionsbeschreibung posten. Anhand der diskutiert werden soll, ob das dahinter stehende Modell die Anforderungen soweit abdecken kann.

Das freut auch mich zu hören. Vielleicht könntet Ihr bei Zeiten auch die gedachten Termine in der Roadmap mal aktualisieren, damit da keine falschen Erwartungshaltungen entstehen.

jela