Beschreibung:
Dieses Dokument veranschaulicht den Konfigurationsprozess in der LMC und gibt detaillierte Infomationen zum Status einer Konfiguration.
Konfigurationsprozess:
In der folgenden Grafik ist der Ablauf eines Konfigurationsprozesses in fünf Schritten abgebildet. Im Folgenden werden die Abläufe in jedem Schritt erklärt.
Schritt 1:
Jeder neue LANCOM Router bringt während des Pairing-Vorgangs seine aktuelle "Running Config" in die LMC. Diese wird als "Basiskonfiguration" (in der Grafik, der grüne Balken) in der LMC hinterlegt.
Die Basiskonfiguration kann dann über die Detail-Konfiguration oder über Einmal-Add-ins (in der Grafik die dunkelblauen Balken) angepasst werden. Alle Änderungen in der Detail-Konfiguration, ändern ausschließlich die Basiskonfiguration. Da die Basiskonfiguration später in die Rolloutkonfiguration einfließt, beinflusst diese natürlich auch indirekt die Rolloutkonfiguration, aber konfiguriert wird erstmal die Basiskonfiguration.
Die Basiskonfiguration kann alternativ auch aus einer Vorkonfiguration stammen. Sofern diese bereits vorhanden ist, wird die Konfiguration aus dem Gerät gar nicht erst ausgelesen.
Die Vorkonfiguration ist eine leere Konfigurationschablone, die in der LMC für jedes Routermodell individuell erstellt werden kann. Man kann so bereits einen Router konfigurieren, der noch nicht mit der LMC gepaired ist.
In der Vorkonfiguration kann dann die Seriennummer hinterlegt werden und sobald das Gerät sich mit der LMC verbindet, wird die Vorkonfiguration für das Gerät als Basiskonfiguration hinterlegt.
Schritt 2:
Die Smart-Konfig Elemente (in der Grafik die hellblauen Balken), sind die Konfigurationsanteile, welche über die Software Defined Features (SD-LAN, SD-WAN, etc.) der LMC erstellt werden.
Alles, was man in der LMC in den Menüs "Netze", "Sicherheit", "Standorte" und "Projektvorgaben" konfiguriert, gehört zu den Smart-Konfig Elementen.
Schritt 3a:
Über OID-basierte Add-ins (in der Grafik die grauen Balken) lassen sich alle Elemente im LCOS konfigurieren, die in der DSC (siehe Abschnitt DSC) hinterlegt sind. OID Add-ins lassen sich auf zwei Arten verwenden, entweder als Standard-Add-in (in der Grafik die blauen Balken) oder als Einmal-Add-in. Dabei ist es wichtig zu verstehen, dass ein Einmal-Add-in schon die Basiskonfiguration ändert, während ein Standard-Add-in erst die Rolloutkonfiguration ändert.
Daher sind die OID Standard-Add-ins auch in der Lage, Smart Konfig-Elemente zu überschreiben. Weil die Änderungen bereits in der LMC stattfinden, können diese in der Detail-Konfiguration eingesehen werden.
- Änderungen durch Einmal-Add-ins werden direkt in der Basiskonfiguration hinterlegt, während die
- Standard-Add-ins nur über die Vorschau der Rolloutkonfiguration eingeblendet werden können.
Nur OID-Add-ins können als Einmal-Add-in verwendet und für jedes LCOS-Betriebssystem genutzt werden, ausser für LCOS FX.
Schritt 3b:
ScriptLine Add-ins (in der Grafik die kleinen orange umrandeten Balken) sind reine Konsolenbefehle im LCOS, welche in JavaScript eingepackt werden. Im Unterschied zu den OID Add-ins, werden diese Konsolen-Befehle nach dem Ausrollen der Rolloutkonfiguration auf dem Gerät ausgeführt.
Dabei kann es sich um Konfigurationsbefehle handeln, die ebenfalls nochmal die Konfiguration anpassen oder über Aktions-Befehle, wie z.B. das Trennen einer Gegenstelle oder dem Löschen der Session-Liste.
ScriptLine Add-ins haben gegenüber den OID Add-ins auch einen Vorteil, dass sie Konfigurationen ändern können, welche nicht im DSC hinterlegt sind.
Schritt 4:
Was in der Grafik unter "Final Config" geführt wird, ist nichts anderes als die Rolloutkonfiguration. Die Rolloutkonfiguration besteht aus der Basiskonfiguration + Smart Konfig-Elementen + Standard-Add-ins. Dabei handelt es sich um die Konfiguration, welche letztlich auf das Gerät ausgerollt wird.
Sie kann über die Detail-Konfiguration eingeblendet werden, in dem man im Reiter oben von Basiskonfiguration auf Rolloutkonfiguration (Vorschau) wechselt.
Die Änderungen aus ScriptLine Add-ins werden beim Einblenden der Rolloutkonfiguration nicht angezeigt, da diese erst nach dem Rollout auf dem Gerät ausgeführt werden.
Nach dem Einblenden der Rolloutkonfiguration, kann man aber über das Menü Konfigurationsaktionen → Konsolenskript anzeigen die Konsolenbefehle aus den ScriptLine Add-ins anzeigen lassen, welche nach dem Rollout auf diesem Gerät ausgeführt werden.
Schritt 5:
Die Running Config ist das was am Ende auf dem Gerät läuft. Sie besteht aus der Rolloutkonfiguration + eventuelle nachträgliche Anpassungen aus ScriptLine Add-ins.
Wichtige Information:
- Bei OID Add-ins wird im Rollout die Konfiguration bestehend aus allen OIDs der DSC komplett an das Gerät übertragen und somit auch in einem Schritt vom Gerät verarbeitet. Im Gegensatz dazu werden die ScriptLine Add-ins immer in einem zweiten Schritt nach der Anwendung der kompletten Konfiguration abgearbeitet.
Das bedeutet dann insbesondere bei Punkten, die in der DSC enthalten sind, dass diese ggf. zweimal kurz hinterneinander und auf unterschiedliche Werte gesetzt werden könnten, sofern es so genutzt wird. Daher sollten OID Add-ins immer bevorzugt werden um Konfigration zu setzen.
- Wichtig zu verstehen ist auch der grundlegende Unterschied zwischen einem Einmal-Add-in und den Standard-Add-ins.
- Das Einmal-Add-in wird zu einem bestimmten Zeitpunkt Änderungen in der Basiskonfiguration vornehmen und diese Änderung wird dann integraler Bestandteil der Basiskonfiguration. Ändere ich also nachträglich ein Einmal-Add-in, hat dies keine Auswirkungen auf Geräte, bei denen ich dieses zuvor einmal angewendet habe. Es wird immer nur einmal verwendet um die Basiskonfiguration anzupassen. Alles was über ein Einmal-Add-in in die Basiskonfiguration eingefügt wurde, kann auch nur über die Basiskonfiguration, also in der Detail-Konfiguration, wieder entfernt werden.
- Dagegen werden die Standard-Add-ins bei jedem Bau der Konfiguration neu durchlaufen und in die resultierende Rolloutkonfiguration eingebaut. Änderungen an den Standard-Add-ins wirken sich also an Geräten im Bestand immer beim nächsten Rollout aus. Insbesondere können die Inhalte dieser Add-ins komplett entfernt werden, wenn das Add-in nachträglich z.B. deaktiviert oder gelöscht wird und die Konfiguration des Gerätes erneut ausgerollt wird.
- Das Einmal-Add-in wird zu einem bestimmten Zeitpunkt Änderungen in der Basiskonfiguration vornehmen und diese Änderung wird dann integraler Bestandteil der Basiskonfiguration. Ändere ich also nachträglich ein Einmal-Add-in, hat dies keine Auswirkungen auf Geräte, bei denen ich dieses zuvor einmal angewendet habe. Es wird immer nur einmal verwendet um die Basiskonfiguration anzupassen. Alles was über ein Einmal-Add-in in die Basiskonfiguration eingefügt wurde, kann auch nur über die Basiskonfiguration, also in der Detail-Konfiguration, wieder entfernt werden.
Konfig-Build-Hierarchie:
Was passiert, wenn z.B. die Basiskonfiguration einen anderen Wert in einer Tabelle enthält, als den, den die Smart Konfig setzen möchte? Und was passiert dann noch mit anderen Werten aus Add-ins?
Zu guter Letzt kann in der Running Config nur eine Konfig hinterlegt werden. Hierzu ist es wichtig die Hierarchie in der LMC zu kennen, welche die Machtverhältnisse der einzelnen Konfig Elemente definiert.
Dabei sieht die Hierarchie etwas anders aus, je nachdem ob man den Bau der Rolloutkonfiguration oder der Running Config betrachtet:
- Die ScriptLine Add-ins können alles was man in der LMC konfiguriert nachträglich überschreiben, da Sie am Ende des Rollouts auf dem Gerät ausgeführt werden. Daher stehen Sie an oberster Stelle der Hierarchie, wenn man die Running Config betrachet. Sie können jeden Wert, der in der Rolloutkonfiguration hinterlegt ist, überschreiben und können die Running Config damit fernab von allen LMC Einstellungen nochmal komplett ändern.
- Die OID-Add-ins stehen hierarchisch an oberster Stelle, wenn es um den Bau der Rolloutkonfiguration geht. Jedoch nur die Standard-Add-ins. Diese sind in der Lage die Konfigurationen zu beinflussen, welche aus den Smart Konfig-Elementen entstehen. Hat man zB über die Netze und Standorte in der LMC einen VPN Tunnel zwischen zwei Standorten gebaut, werden die Konfigurationsparameter für die VPN Tunnel fest in der Rolloutkonfiguration der betroffenen Geräte hinterlegt.
Diese können nur über die Vorschau der Rolloutkonfiguration angeschaut, aber nicht verändert werden. Möchten Sie z.B. für einen VPN Tunnel die Verschlüsselungsalgorithmen ändern, geht das nur über ein OID-Standard-Add-in. Oder möchten Sie, dass die Smart Config VPN Tunnel über RSA, anstelle von PSK authentifiziert, geht das nur über ein passendes OID-Standard-Add-in. - Die Smart Konfig Elemente können Werte aus der Basiskonfiguration überschreiben. Das bedeutet, wenn über die Detail-Konfiguration die Basiskonfiguration angepasst wurde und sie z.B. für das IP Netzwerk INTRANET, die IP 172.16.0.2 konfigurieren, die Smart Konfig aber über Netze/Standorte diesem Gerät für das Netzwerk INTRANET die IP 172.16.0.1 zuweist, wird am Ende in der Rolloutkonfiguration die 172.16.0.1 stehen.
- OID Add-ins, welche als Einmal Add-in genutzt werden, werden direkt in die Basiskonfiguration eingefügt und werden somit ein Bestandteil davon. Daher werden Sie in der Grafik nicht erwähnt. Änderungen an der Basiskonfiguration können von den Smart Konfig-Elementen und allen Add-ins überschrieben werden.
Konfigurations-Status in der LMC:
Nachdem es im oberen Abschnitt Informationen zum Prozess des Konfigurationszusammenbaus gegeben hat, wollen wir uns der Frage widmen, wann der Konfigurations-Status eines Gerätes auf "nicht aktuell" gesetzt wird.
Grundsätzlich gilt: Jegliche Änderung an der Konfiguration in der LMC führt dazu, dass der Konfigurations-Status der betroffenen Geräte auf "nicht aktuell" gesetzt wird.
Eingrenzen kann man das folgendermaßen:
- Änderungen an den Netzen → Alle Geräte, denen das Netz zugewiesen wurde.
- Änderungen an den VPN Einstellungen → Nur Gateways, also Router und Firewalls.
- Änderungen an den WLAN Einstellungen → Nur Geräte mit WLAN.
- Änderungen an den Switch Port Vorgaben → Nur Switches.
- Änderungen an den Add-ins, zugewiesen per Netz → Alle Geräte mit dem angegebenen Betriebssystem, die dem Netz zugewiesen sind.
- Änderungen an den Add-ins, global über Variable zugewiesen → Alle Geräte mit dem angegebenen Betriebssystem, bei denen die Variable den entsprechenden Wert annimmt.
- Globale Änderungen in den Projektvorgaben wie z.B. Auto Updater → Alle Geräte, die den Auto Updater anbieten.
- Zudem können Geräte den Status "nicht aktuell" durch das Aktivieren eines Features auf den Geräten, sowie nach einem Firmware Update anzeigen, da die Konfiguration mit neuen Features von der bisherigen abweichen könnte.
Bei lokalen Änderungen, hängt der Geräte-Status von den Einstellungen unter Projektvorgaben → Basis → Konfiguration → Lokale Geräte-Konfigurationsänderungen ab.
In diesem Menüpunkt gibt es drei Optionen:
In die LMC übernehmen:
Bei dieser Option werden alle lokalen Änderungen in die LMC übernommen und der Konfigurations-Status des Gerätes bleibt auf "Aktuell" stehen, wenn lokale Änderungen durchgeführt werden.
Damit würde also ein Wert, der vorher gar nicht in der Basiskonfiguration zu sehen war, sondern nur über die Vorschau der Rolloutkonfiguration eingeblendet wurde, plötzlich auch in der Basiskonfiguration stehen.
Ein durch Smart Konfig gesetzter Wert, der der lokalen Änderung widerspricht, wird sich am Ende aber trotzdem durchsetzen. Das bedeutet, dass obwohl sich lokal die Konfiguration ändert, die Rolloutkonfiguration nicht verändert wird und das Gerät daher auch auf aktuell bleibt, obwohl die Konfigration der Running Config von der Rolloutkonfiguration abweicht.
Ein erneutes ausrollen würde, den Wert wieder überschreiben und die Smart Konfig-Werte wieder setzen. Das Gegenteil ist der Fall, wenn man in der LMC die Konfiguration bearbeitet. Schreiben Sie in der LMC einen Wert in die Basiskonfiguration, welcher der Smart Config widerspricht, gewinnt auch hier die Smart Config, aber der Konfigurations-Status des Gerätes wird dennoch auf "nicht aktuell" gesetzt.
In der LMC protokollieren:
Bei dieser Option werden alle lokalen Änderungen nur in das LMC Geräte-Log protokolliert. Die Konfigration wird nicht in die Basiskonfiguration übernommen.
Das bedeuet, dass jegliche lokale Änderungen den Konfigurations-Status eines Gerätes auf "nicht aktuell" setzen und der lokal geänderte Wert immer beim erneuten Ausrollen der Konfiguration überschrieben wird.
Automatisch zurücksetzen:
Bei dieser Option, wird jede lokale Änderung von der LMC zurückgesetzt. Die lokalen Änderungen werden an die LMC gemeldet, die dann automatisch den Rollout anstößt.
Wichtige Information:
Egal welcher Modus gewählt wird, grundsätzlich sollte mit lokalen Änderungen auf den Geräten vorsichtig umgegangen werden. Die LMC hat den Anspruch, das führende Management System zu sein.
Die Übernahme von Änderungen, welche lokal auf dem Gerät ausgeführt werden, kann aber in vielen Situationen hilfreich sein, in anderen sogar notwendig, wenn sich die Konfiguration des Gerätes automatisch ändert, also z.B. Änderungen durch Aktionstabelle/Cron Job oder bei der Verwendung des PublicSpot im LCOS mit automatischer Erzeugung von Nutzern.
Grundsätzlich ist diese Funktion aber mit Vorsicht zu genießen und Änderungen sollten bevorzugt über die SmartConfig und Add-ins erfolgen. Lokale Änderungen sollten eine Ausnahme bilden und es muss klar sein dass dabei der Status nicht immer zu 100% korrekt übermittelt werden kann.
Was ist DSC?
Beim DCS handelt es sich um ein von LANCOM Systems entwickeltes internes Datenmodel, welches die Konfigurationsstruktur der Betriebsysteme LCOS und LCOS LX abbildet. Es dient dazu, die komplexen Konfigurationsdaten in einer hierarischen und strukturierten Form darzustellen, was insbesondere für die grafische Benutzeroberfläche der LMC Detail-Konfiguration und LANconfig von Bedeutung ist.
Wer schon länger mit LANCOM arbeitet, hat vermutlich schon bemerkt, dass die Menüstruktur auf der Konsole nicht 1:1 zu der Menüstruktur der LMC Detail-Konfiguration oder LANconfig passt. Genau diese Übersetzung übernimmt das DSC.
In der Detail-Konfiguration werden daher auch nicht zwingend alle Konfigurationsmöglichkeiten abgebildet. Es gibt einige Schalter, die nur im LCOS auf der Konsole gesetzt werden können, weil entschieden wurde, diese nicht in die DSC zu übertragen. Hier haben ScripLine Add-ins einen Vorteil, dadurch dass es sich dabei um reine Konsolenbefehle handelt, kann die LMC mit Ihrer Hilfe auch die Schalter im LCOS bedienen, die nicht im DSC hinterlegt sind.
Fazit:
Das Ziel sollte sein, die Konfiguration ausschließlich über Smart Konfig-Elemente und Add-ins abzubilden. Lokale Änderungen an den Geräten, sowie Änderungen in der Detail-Konfiguration, also an der Basiskonfigration, sollten bestenfalls zu 100% vermieden werden. Die vollständige Konfiguration sollte nur aus den Add-ins + Smart Konfig-Elementen kommen (auch die Underlay-Konfiguration, mit der Sie die Geräte vorab bestücken, um Sie in die LMC zu bringen).
Nur so ist sichergestellt, dass bei einem Hardwaretausch keine lokale Konfigurations-Sicherung gemacht werden muss. Wenn die komplette Konfig aus der LMC kommt, kennt die LMC diese auch und kann damit auch andere Geräte bestücken. Änderungen in der Basiskonfiguration oder lokale Änderungen am Gerät kann die LMC nicht nachhalten und würden dann bei einem Gerätetausch verloren gehen.
