VLANs dokumentieren



  • Moin,

    ich habe nun schon einiges darüber gelesen, wie man mit i-doit VLANs dokumentieren könnte. Die beiden Möglichkeiten, die ich gefunden habe werden aber noch einige Fragen für mich auf:

    • virtuelle Interfaces

      • Muß dann das VLAN auf jedem Switch separat angelegt werden, auf dem es konfiguriert ist ?

      • Wie bekomme ich eine Übersicht über die vergebenen VLANs ?

    • eigene Objektdefinition

      • Wie bekomme ich die VLAN-ID eingebaut ?

      • Wie wird die Verknüpfung zum IP-Netz (L3) und zu den Switch-Ports hergestellt ?

    Hat jemand möglicherweise eine Konfiguration zur Switch-übergreifenden Verwaltung von VLANs erzeugt, die er hier erläutern könnte ?

    Vielen Dank und Schöne Grüße.

    sh


  • administrators

    Hallo,

    ohne jetzt mal genau auf die Anforderungen einzugehen: Wir bauen die VLAN Dokumentation dieses Jahr noch um, wahrscheinlich relativ analog zu den heutigen Layer-3 Netzobjekten. Dann sollte das ganze etwas intuitiver von der Hand gehen…

    Viele Grüße,

    Daniel



  • Vielen Dank für die Info. Aber ein paar Antworten auf meine Fragen hätte ich doch gern gehabt. Vielleicht stelle ich mich ja einfach nur zu blöd an ?
    Oder ist das Thema schon irgendwo ausführlicher beschrieben worden ?

    Schöne Grüße.

    sh


  • administrators

    Okay, dann schreibe ich es etwas ausführlicher =). Ich will mich halt ungerne jetzt technisch im Detail über etwas auslassen, was in wahrscheinlich drei Monaten wesentlich anders funktioniert. Deswegen beschriebe ich das Ganze mal aus heutiger und aus zukünftiger Sicht.

    virtuelle Interfaces
            Muß dann das VLAN auf jedem Switch separat angelegt werden, auf dem es konfiguriert ist ?

    Zzt.: Ja. Die VLAN Konfiguration muss auf jedem Switch einzeln eingepflegt werden. Grundstein dafür war damals, daß technisch gesehen VLAN Konfigurationen wirklich auf jedem Switch einzeln liegen. Heutzutage werden die Konfigurationen aber meistens per Protokoll zentral verwaltet und auf viele Switche distributiert, so daß der Eindruck entsteht, es wäre eine globale Datenbank.

    In Zukunft: Werden wir eine globale Verwaltung von VLANs schaffen, wahrscheinlich ähnlich wie derzeit die Layer-3 Netze.

    Wie bekomme ich eine Übersicht über die vergebenen VLANs ?

    Derzeit: Garnicht.

    In Zukunft: Über die globalen Layer-2 Netzobjekte.

    eigene Objektdefinition
            Wie bekomme ich die VLAN-ID eingebaut ?

    Derzeit: Ich persönlich würde den Titel des logischen Interfaces nach der VLAN ID benennen. Alternativ dazu kann man entweder über das Beschreibungfeld oder vielleicht das Feld "Typ" dafür benutzen.

    In Zukunft: Über die globalen Layer-2 Objekte.

    Wie wird die Verknüpfung zum IP-Netz (L3) und zu den Switch-Ports hergestellt ?

    Jetzt und in Zukunft: garnicht. Switchports haben kein Layer-3 Netz zugeordnet. VLANs haben keine fest zugeordneten Layer-3 Netze. Viele Netzwerker tuen dies natürlich, also verknüpfen  immer ein IP-Netz mit einem VLAN, dies ist aber definitiv nicht verpflichtend notwendig. Im neuen Modell werden wir vielleicht eine Möglichkeit schaffen, Layer-3 Netze mit Layer-2 Netzen zu verknüpfen. Aber auf Portebene wird dies definitiv nicht möglich sein, weil es einfach nicht sinnvoll ist. Die Verknüpfungskette sieht es derzeit vor, Layer-3 Netze mit Hostadressen und Hostadressen mit Interfaces zu verknüpfen.

    Ich hoffe ich konnte ein wenig helfen…



  • Vielen Dank für die ausführliche Antwort 🙂 Aktuell klingt das für mich allerdings so, als ob sich VLANs erst mit Einführung der L2-Netzobjekte sinnvoll verwalten lassen.
    Ein paar Anmerkungen habe ich aber trotzdem noch:

    @dkirsten:

    Muß dann das VLAN auf jedem Switch separat angelegt werden, auf dem es konfiguriert ist ?

    Zzt.: Ja. Die VLAN Konfiguration muss auf jedem Switch einzeln eingepflegt werden. Grundstein dafür war damals, daß technisch gesehen VLAN Konfigurationen wirklich auf jedem Switch einzeln liegen. Heutzutage werden die Konfigurationen aber meistens per Protokoll zentral verwaltet und auf viele Switche distributiert, so daß der Eindruck entsteht, es wäre eine globale Datenbank.

    Technisch gesehen hast Du natürlich Recht, VLAN 3 auf Switch A muß nichts mit VLAN 3 auf Switch B zu tun haben. Ich kenne aber keinen (ernsthaften) Netzwerk-Admin, der das so machen würde, zumal die Switches ja in der Regel miteinander verbunden sind und spätestens dann wird man sich für netzwerkweit-eindeutige VLAN-IDs entscheiden. Selbst wenn sie am Ende nicht automatisch auf die Switches verteilt werden.

    @dkirsten:

    Wie wird die Verknüpfung zum IP-Netz (L3) und zu den Switch-Ports hergestellt ?

    Jetzt und in Zukunft: garnicht. Switchports haben kein Layer-3 Netz zugeordnet. VLANs haben keine fest zugeordneten Layer-3 Netze. Viele Netzwerker tuen dies natürlich, also verknüpfen  immer ein IP-Netz mit einem VLAN, dies ist aber definitiv nicht verpflichtend notwendig. Im neuen Modell werden wir vielleicht eine Möglichkeit schaffen, Layer-3 Netze mit Layer-2 Netzen zu verknüpfen. Aber auf Portebene wird dies definitiv nicht möglich sein, weil es einfach nicht sinnvoll ist. Die Verknüpfungskette sieht es derzeit vor, Layer-3 Netze mit Hostadressen und Hostadressen mit Interfaces zu verknüpfen.

    Hier bin ich etwas anderer Meinung. Bei der Verknüpfung von L2 und L3 Objekten kann man sicher streiten. Da es aber, wie Du ja auch schreibst, gängige Praxis ist wäre es schön, wenigstens die Möglichkeit vorzusehen. Aus Sicht des Hosts ist es sicher in Ordnung, sich auf die Verknüpfung von Interfaces mit L3-Objekten zu beschränken. Wenn ich jedoch die Konfiguration eines Switches dokumentieren will, werde ich normalerweise nicht die IP des angeschlossenen Hosts wissen wollen, sondern welches VLAN auf diesem Port konfiguriert ist. Im Fall von Trunk-Ports eventuell sogar eine Liste von VLANs.

    Schließlich habe ich noch eine andere Frage: Im aktuellen Demo-System kann ich problemlos IPs in einem Netz doppelt vergeben, sowohl an den gleichen Server, als auch an verschiedene. Ist das so beabsichtigt und sollte da nicht wenigstens eine Warnung ausgegeben werden ?

    Vielen Dank und Schöne Grüße.

    sh


  • administrators

    Jau also nochmal eben zur Erklärung, vielleicht ist es aus dem letzten Post nicht so deutlich hervorgegangen. Das nächste Update zum Thema Netzwerk (L2 und L3) wird in Kürze vorgenommen und ist aber noch nicht komplett durchdesigned. Ein paar Eckdaten stehen aber auf jeden Fall fest, z.B. daß es eine wie von Dir beschriebene globale VLAN Verwaltung definitiv geben wird.
    Natürlich werden Switchports mit VLANs verknüpft werden. Switchports werden allerdings nicht mit Ip-Netzen verknüpft. Denkbar wäre aber natürlich eine Anzeige in der Portübersicht, wo man vielleicht folgende Darstellung generieren könnte:

    Portname - zugewiesene VLANs - Layer 3 Netze - Angeschlossenes System

    Ist jetzt erstmal nur so eine Idee, die Designphase wird sicherlich noch einiges an Änderungen mit sich bringen.

    Zu Deiner letzten Frage: Das Erlauben von doppelten IP-Adressen ist optional, die Einstellung befindet sich in der config.inc.php:

    $g_unique_check = array(
            "ip_address"    => false,
            "hostname"              => false,
            "object_title"  => false
    );



  • Hallo,

    das Thema Vlan ist sehr interessant.

    Ich bitte beim Design darauf zu achten, das auch IP-Adressen auf sogenannte Switchport gesetzt werden. Bei einem Layer3 Switch z.B. alle Switche von Cisco die mit einer 3xxx beginnen (Cisco 3560G). Durch den Befehl no switchport wird der Port zum Layer3 und kann mit einer IP versehen werden. Da dies sehr oft und eigentlich schon zum Tagesgeschäft wird, solte dies Beachtung finden.
    Es gibt z.Z. ein Tool Cenf.org von Herrn Hoffmann, der ein Auslesen der Vlans mit einem snmp-scanner durchführt. Der Ansatz ist sehr gut, da in einer Zwischen-Datenbank mit Cenfscan und später das einlesen in die CMdB mit Cenfsync stattfindet. Auch er benötigt nun die Objekte, um eine klare Zuweisung von Vlan-Switchport-HostAdresse(oder IP-Adresse auf dem Interface) speichern zu können. Weiterhin bitte ich darauf zu achten, dass auf allen Interfaces auch noch IP-Helper Funktionen wie dhcp-helper oder tftp-option gesetz werden müssen. Ein Zusatzfeld zur Verknüpfung am Switchport währe daher die Lösung.



  • Darf ich mal nachfragen wie es mit dem Update inkl. VLANs etc. aussieht? Danke (=


  • administrators

    @DigiDaniel:

    Darf ich mal nachfragen wie es mit dem Update inkl. VLANs etc. aussieht? Danke (=

    Darfst Du, wird noch etwas dauern, wir bauen seit Wochen den Import/Export um, dann geht es direkt in ein Kundenprojekt und währenddessen werden wir den Umbau parallel machen. Das heisst in unverbindlichen Zeiten gesprochen, daß wir ca. in 2 -3 Wochen inhaltlich mit dem Thema anfangen werden…



  • Der Vollständigkeit halber auch noch einmal ein Verweis auf zwei weitere wichtige Features in diesem Zusammenhang: Vlan stacking/Link Aggregation (http://forum.i-doit.org/index.php/topic,2475.0.html)



  • @sehe:

    @dkirsten:

    Muß dann das VLAN auf jedem Switch separat angelegt werden, auf dem es konfiguriert ist ?

    Zzt.: Ja. Die VLAN Konfiguration muss auf jedem Switch einzeln eingepflegt werden. Grundstein dafür war damals, daß technisch gesehen VLAN Konfigurationen wirklich auf jedem Switch einzeln liegen. Heutzutage werden die Konfigurationen aber meistens per Protokoll zentral verwaltet und auf viele Switche distributiert, so daß der Eindruck entsteht, es wäre eine globale Datenbank.

    Technisch gesehen hast Du natürlich Recht, VLAN 3 auf Switch A muß nichts mit VLAN 3 auf Switch B zu tun haben. Ich kenne aber keinen (ernsthaften) Netzwerk-Admin, der das so machen würde, zumal die Switches ja in der Regel miteinander verbunden sind und spätestens dann wird man sich für netzwerkweit-eindeutige VLAN-IDs entscheiden. Selbst wenn sie am Ende nicht automatisch auf die Switches verteilt werden.

    Das VLAN-IDs eindeutig sind wünscht sich sicherlich jeder Admin. In der Realität ist das leider aber nicht immer möglich. Sobald man Schnittstellen zu anderen Layer 2 Netzen hat kommt es potentiellen Überschneidungen. In unserem Fall haben wir z.B. verschiedene Peering Partner an verschiedenen Standorten und Vorgaben von Kunden die zu doppelten VLAN IDs führen. In meinen Augen sollte ein "unique" check daher analog zu IP-Adressen optimal sein, es aber grundsätzlich möglich sein doppelte Vlans anzulegen.


 


Datenschutz / Privacy Policy