Lokale IP-Adreßräume sollten in Zeiten von VRF, VPN und Virtualisierten Instanzen nicht global einzigartig sein.

Zumindest Netzbereiche müssen mehrfach anlegbar sein, nicht nur als aufeinander aufbauende Supernets, sondern mit gleicher Maskierung.

Aktuell kommt bei der Anlage eines Layer-3-Netzes beim Check eine Overlapping Warning, dass das Netz andere Netzbereiche überschneidet (das ist mit einem Supernet "Global v4" keine Kunst).

Der Trick sollte hier aber normalerweise sein, das Layer3-Netz einem distinguierten (von anderen Netzen abgeschlossenen) Layer2 Netz zuzuordnen, dann müßte die Kollision / Overlapping verschwinden bzw. nicht mehr angezeigt werden. Oder ist das so zu verstehen, daß man nur die doppelt angelegten / sich theoretisch überschneidenden Netze angezeigt bekommen soll? Das wird mit der Zeit aber sehr unübersichtlich….

Zumindest die nicht-öffentlichen Netze sollten von einer Overlapping Warning ausgenommen werden, weil diese dazu tendieren, in größeren
IT-Installationen (oder Dokumentationen, siehe mein Vorredner / TE) doppelt aufzutauchen.

Dazu zählen auch die neuen CGN-Netzbereiche, die von RIPE nur für Carriergrade-NAT Zwecke reserviert wurden.

Zusammenfassend geht es hier um folgende Standards:

RFC1918:
(Private address)

• 10.0.0.0/8 (10.0.0.0-10.255.255.255)
• 172.16.0.0/12 (172.16.0.0-172.31.255.255)
• 192.168.0.0/16 (192.168.0.0-192.168.255.255)

RFC6598:
(Shared address /CGNAT)

• 100.64.0.0/10 (100.64.0.0-100.127.255.255)

RFC 5735:
(Link local)

• 169.254.0.0/16 (169.254.0.0-169.254.255.255)

Evtl. eine Idee für die nächsten Updates?

Gruß,
Frank

Hallo,

vielen Dank für das Update. Das freut mich sehr, daß es die Darkfiber Dokumentation in i-doit geschafft hat. Welche kommerzielle Version (1.5?) ist hier genau gemeint? Bezieht sich das auf das kommende Update 1.5.3?

An der Beantwortung habe ich auch Interesse und verweise noch zusätzlich auf diesen Thread:
http://forum.i-doit.org/index.php/topic,3358.msg10994.html#msg10994

Hallo Maurice,

nein, das war offenbar noch nie vorgesehen. Offenbar scheint es in der IT-Landschaft -außer bei dir und bei uns- nicht vorzukommen, daß Patchfelder fest back-to-back miteinander verbunden werden. Oder man kann sich nicht vorstellen, daß das manuelle Verbinden der Anschlüsse fast genauso lange dauert wie das physische Auflegen der Kabel. Wir haben das vor mittlerweile fünf Jahren angesprochen gehabt, es hat mehrere Threads gegeben in denen das besprochen wurde, aber bei synetics offenbar niemanden erreicht.

Du hast das ja im letzten Jahr auch schon einmal angefragt gehabt, so daß eigentlich der Bedarf der Kunden langsam offensichtlich sein sollte. Hat trotzdem niemanden wirklich interessiert. Nicht mal eine Rückmeldung, "ja machen wir, nein machen wir nicht" war dazu zu lesen. Hier mal die Threads dazu:

Deiner von Oktober 2014: http://forum.i-doit.org/index.php/topic,3507.msg11471.html
Der alte von April 2010: http://forum.i-doit.org/index.php/topic,1492.msg6604.html
Noch ein alter, April 2010: http://forum.i-doit.org/index.php/topic,1475.msg8268.html

Ich habe es mittlerweile aufgegeben danach zu fragen.

Gruß,
Frank

Hallo Maurice,

diese Frage haben wir uns vor 4 Jahren auch alle schon gestellt. Es gibt schon einen Thread hierzu, den könnte man evtl. mal reaktivieren.

http://forum.i-doit.org/index.php/topic,1475.msg8268.html

Ich bin gerade nicht ganz sicher, was die aktuelle Version angeht, ob es da schon Fortschritte in der Angelegenheit gibt.

Stimme zu! Ist ein nerviges Problem, was mit wenig Aufwand gelöst werden könnte.

Einen Linux-Server, egal ob nun virtuell oder dediziert, kann man durchaus sehr sicher machen. Ich würde keinen vServer nehmen, da die CMDB durchaus sehr ressourcenintensiv werden kann (vor allem bei mehreren Mandanten in nicht quantifizierter Größe). Du willst genug Ressourcen übrig haben.

Wenn Sicherheit das zentrale Thema ist (davon gehe ich nach Deinen bisherigen Angaben aus), würde ich das um eine Firewall/VPN-Lösung erweitern und ansonsten von "außen" gar keine Zugriffe oder eben nur per bereits angesprochener HTTP-BASIC-AUTH erlauben. Die läßt sich einfach einrichten und ist, da sie direkt im Apache stattfindet, nahezu unknackbar - zumindest wenn das Passwort vernünftig gewählt ist.  Übrigens kann man über den Weg auch statische Kundennetze (oder eben VPN-IP-Ranges) freischalten und andere außen vor lassen. Dann findet für die "richtigen" Nutzer natürlich auch keine 2. Passwortabfrage statt, sondern nur für Leute, die von unbekannten IP-Ranges darauf zugreifen. Die sicherste Lösung ist aber die "reine" VPN-Variante, d.h. andere externe Zugriffe sind nicht möglich. Nur, wer im VPN sitzt, kann auf die CMDB zugreifen. Ist im Prinzip wie ein Firmennetz, und kann auch mit solchen kombiniert werden.

Zufällig sind wir übrigens ISP, und haben solche VPN-Installationen schon mehrfach (auch für prominente Kunden) im Einsatz. Ich mag hier auf dem Board keine öffentliche Werbung machen, aber wenn Du Interesse hast und Unterstützung brauchst, kannst Du dich per PN an mich wenden.

Gruß,
Frank

Ich finde schon, daß dies noch ein relevanter Bereich ist, der Teil der Dokumentation mit i-doit sein sollte und nicht den Rahmen sprengt. Weshalb sollte eine IT-Dokumentation bei Glasfasern an der Layer2-Grenze aufhören? Wenn ich schon Kupferkabel, deren Länge und Farbe sowie sonstige Beschaffenheit, dokumentieren kann, sollte das doch wohl auch mit anderen Übertragerstandards gehen. Allerdings ist eben die Glasfasertechnik nicht eben unkomplex und die vielen Ebenen, die hier ja angesprochen wurden, sollten durchaus von vorneherein berücksichtigt werden, z.b. mit Containerobjekten. Ich habe mich noch nicht entschieden, ob wir da eine eigene Kategorie zusammenzimmern oder auf eine etwaige Umsetzung innerhalb von i-doit warten sollten. Es wäre natürlich hilfreich, wenn es so etwas wie eine Aussage dazu von Seiten der Entwickler geben würde.

Ich hoffe, synetics nimmt hiervon Notiz und nimmt das vielleicht in eine (interne?) Roadmap auf. Ich bin, wie gesagt, gerne mit Vorschlägen oder "Anschauungsunterricht" behilflich. Wenn jemand bei s. das liest, darf er sich gern bei mir melden (E-Mail Adresse im Profil).

Idee: Einfach eine HTTP BASIC AUTH davor schalten? (.htaccess)
Das ist nach aktuellem Technologiestand relativ sicher.

Das Passwort ließe sich zudem unabhängig von i-doit-Credentials verwalten und auch für mehrere User einrichten. Und für die sichere Datenübertragung könnte man SSL zuschalten.

Nachtrag: Die Objekte werden natürlich auch nicht angelegt, d.h. nicht nur ein Anzeigefehler, sondern die ganze Funktion ist tot.

Hallo,

das Anlegen von Objekten aus Templates funktioniert nicht mehr.

Wenn man auf "Objekte aus ausgewählten Templates erstellen" klickt, erscheint keine Liste der angelegten Objekte, sondern ein IFRAME, in welchem sich wieder die g anze i-doit Oberfläche öffnet. Es ist egal, welches Template benutzt wird oder ob es neu angelegt wird. Nachvollziehbar in der Demo 1.4.1.

Bugfix?

Ich vermute, das von uns beiden gewünschte wird nur mit rekursiven Container-Objekten gehen, also "Kabel" (Wellenlänge) im Kabel (Faser) im Kabel (LWL) im Kabel (Duct). Sonst dokumentierst du am Ende wirklich jede Faser (und wir jede WL) einzeln, und zwar als Kabel, nur eben nicht aus Kupfer.

Hybride Lösungen sollten am Ende auch möglich sein, beispielsweise CWDM/DWDM. Das geht von der Topologie her so:

Switch Port 1 (DWDM-Laser, Kanal 25) -> DWDM-Multiplexer Port 1 -> Bandfilter Port 1 -> CWDM-Multiplexer 1551nm Port 1 -> Dark Fibre  (Stecker: LC/APC) ==== 5km ==== Dark Fibre (Stecker: E2000/APC) <- CWDM-Multiplexer 1551nm Port 1 <- Bandfilter Port 1 <- DWDM-Multiplexer Port 1 <- Switch Port 1 (DWDM-Laser, Kanal 25)

Das ist eine konkrete Anwendung und ein Beispiel aus der Praxis. Bei der Implementation wären wir gern behilflich, auch mit vor-Ort Praxistermin bei uns in den RZ, wo man sich die einzelnen zu dokumentierenden Komponenten auch mal anschauen kann.

Meiner Idee nach müßten sich die einzelnen Verbindungsobjekte wie Kupfer-Kabel verhalten, nur daß sie die technikspezifischen Parameter beherbergen, wie z.b. Wellenlänge (nm), Faserstärke/Typ, Kabeltyp (zb. SingleMode) bzw. Marke (zb. Lucent Allwave) .

Das ganze sollte noch so erweiterbar sein, daß jede dieser 24 Fasern mit bis zu 80 Wellenlängen per DWDM bestückbar sein sollte. Die dazu notwendigen Multiplexer könnten als Gerät ja auch schon heute eine Glasfaser (ein "Kabel") als Eingang / Ausgang anbinden, nur läßt sich das derzeit schwer abbilden, indem man z.b. den Muxer als einen Switch darstellen würde. Die WL muß in der Faser eine 1:n Verbindung darstellen (1 Faser, 80 WL), und diese wiederum im Kabel 1:n (1 Glasfaserkabel, 72 oder 128 Fasern). Da die Wellenlänge ansich aber in jedem Fall eine 1:1 Verbindung wie ein normales Kabel ist, muß der Verbindungspfad von Punkt A nach Punkt B erhalten bleiben. Ich bin nicht sicher, wie man das derzeit im i-doit richtig abbilden würde.

Container-Objekte?

Hallo,

wir betreiben als ISP mehrere Lokationen in EU, die untereinander via DarkFibre und/oder Wellenlänge angebunden sind. Innerhalb der RZ gibt es die klassische Kombination LWL-Vorverkabelung + Patch zwischen A- und B-Standort. Die DF-Strecken und manchmal auch die inhouse patches muxen wir aus Kapazitätsvervielfachungsgründen branchenüblich mit WDM-Technik (CWDM/DWDM).

Meine Frage (zweiteilig) lautet nun:

1. Wie dokumentiert man zum Einen optische Links, die aus physischen Strecken bestehen? Sind das einfach "Kabel", nur eben nicht aus Kupfer? Wie wirkt sich das auf Patchpanel oder Anschlüsse an z.b. Switches oder Router aus? Können diese "anderen Kabel" dann auch direkt an Netzwerkports angelegt werden und verbinden diese? Können diese Lokationsunabhängig (z.b. zwischen Stadt 1 - RZ 1 und Stadt 2 - RZ 1) verbunden werden?

2. Wie dokumentiert man zum Anderen die gemultiplexten Wellenlängen, die physisch auf den DF-Strecken aus 1) laufen, aber natürlich eigene Kanäle mit eigener darunterliegender Netzwerkebene darstellen?

Ich könnte zum Thema WDM-Multiplexer und die darunterliegende Komplexität noch einen ganzen weiteren Fragenkatalog schreiben, aber ich hatte ja nur eine zweiteilige Frage versprochen. More to come

Gruß,
Frank

Hallo,

ich gehe noch einen Schritt weiter, und möchte die Frage nach den Sicherungsautomaten anschließen. Es gab mal vor gefühlten 100 Jahren (und in der damaligen OS Version) die Möglichkeit, Sicherungskästen (Verteilerkästen mit Sicherungselementen) abzubilden (Reste davon finden sich noch in der DB) und zusammen mit noch hinzuzufügenden Elementen wie Lastschaltern, Zählern, LS- und FI-Schaltern und anderen typischen Hutschienenelementen ließe sich natürlich damit dann auch eine ausgewachsene UV oder NSHV abbilden, also Dein Ziel, StefanP74. (Die Entsprechung von Patchpanels im Netzwerkschrank wäre dann z.b. eine Phönix-Klemme in der NSHV/UV?)

Ich finde, die Verteilerkästen mit ihren Leistungsabgabewerten sowie Eingangskapazität in V und A, bestehende örtliche Hutschienendokumentation (wie im Serverrack die HE), sowie die evtl. auch mehrphasig und redundant zugeführte Eingangsverkabelung sind wichtig bzw. gehören zu einer vollständigen Elektro-UV-Dokumentation; wenn der Strompfad schon vom Versorger aus bis zum Servernetzteil abgebildet werden soll, müssen die einzelnen Verteilerelemente eben auch mit ihren jeweiligen Kapazitäten dokumentiert werden, insbesondere auch Phasenverteilung (wahrscheinlich nicht trivial!!). Bei uns gibt es in den RZ eigentlich keine Verteilerkästen OHNE LS-Elemente und/oder Zählern, daher hätten wir da einen großen Anwendungsfall.

Möglicherweise ist ja diesbezüglich bei synetics schon etwas in Planung?

tagged VLANs ein- bzw. mehrdimensional (QinQ/Double-tagging), wie von freddy geschrieben, bitte auch in die Überlegungen mit aufnehmen. Das ist auch für die Dokumentation von Switchen und Routern sowie Routing allgemein extrem überlebenswichtig. Danke!

Ich würde ja sagen, das ist eine Appliance.

Kann es sein, daß auch der Upload einer Datei nicht mehr möglich ist? Ich habe jedenfalls kein Symbol mehr dafür…

Das Problem ist in der 0.9.9-6 leider nicht behoben. Im demo-System demo.i-doit.com habe ich soeben ein Template "SUN PDU" mit 8 Anschlüssen angelegt, und daraus versucht, das Objekt "PDU 1099" zu erzeugen. Wie sich im Demo-System schön nachvollziehen läßt, werden die Anschlüsse aus dem Template (1 Eingang, 8 Ausgänge) völlig falsch zugeordnet.  Screenshot
Unter den Anschlüssen ist unterdessen nur ein falsch zugeordneter Eingang, stattdessen aber gar keine Ausgänge mehr zu sehen. Screenshot

Irgendwas läuft da mächtig schief!!

gruß,
Frank