[R884VA] Lanconfig Config Deployment und Bundle0/1 Mac-Addresse

[sw2090]

Moin,

bin gerade auf folgende Problematik gestossen:

wir setzen Lancoms auf indem wir diese in Lanconfig aufnehmen, über Lanconfig upgraden und mit einer Config beschicken.
Das funktioniert auch soweit gut. Die Config ist immer die gleiche da sich die Router nur in Hostname,IP(s) und Einwahldaten unterscheiden.
Nun haben wir aber festgestellt dass dabei teilweise auch Macaddressen exportiert und auf dem neuen Gerät dann überschrieben werden.
Reproduzierbar aber nur bei den interfaces Bundle0 bzw 1. Diese verwenden wir jedoch nicht da wir kein Trunking benötigen. Insofern tut das der Funktionalität des Routers ansich hier nichts.
Allerdings bekomme ich die Router so nicht in unser Monitoring weil sie sich hier wegen obiger Problematik selber überschreiben.

Kann ich diese Interfaces einfach aus dem xml löschen damit di nicht überschrieben werden? Wie lässt sich das am elegantesten für die Router die schon in Betrieb sind ändern?

Grüsse
Sebastian

[Jirka]

Hallo Sebastian,

Allerdings bekomme ich die Router so nicht in unser Monitoring weil sie sich hier wegen obiger Problematik selber überschreiben.

das kann ich so jetzt nicht nachvollziehen.

Kann ich diese Interfaces einfach aus dem xml löschen damit di nicht überschrieben werden?

xml?
Ja, kannst Du löschen.
Kannst Du auch in LANconfig machen (Konfiguration -> Schnittstellen -> LAN -> LACP-Schnittstellen -> ... -> MAC-Adresse löschen).

Wie lässt sich das am elegantesten für die Router die schon in Betrieb sind ändern?

Je nachdem, ob das jetzt 3 oder mehr sind per Hand mit einem 'default /Setup/LAN/Interface-Bundling/Interfaces' auf der Konsole oder man packt selbigen Befehl in eine Scriptdatei (abschließendes Enter nicht vergessen) und spielt die bei den entsprechenden Geräten ein.

Viele Grüße,
Jirka

[sw2090]

Unser Monitoring nutzt nagios/icinga. Das erzeugt die Assets anhand der Mac-Addresse. Aus irgendeinem Grund ist icinga der ansicht wenn bei zwei Geräten das selbe interface die selbe mac hast ist das das gleiche Gerät und überschreibt mir das Asset.
Somit kriege ich nie mehr als einen Lancom da rein...

Nur der Nachvollziehbarkeit halber

[sw2090]

Ich frage mich eher nach dem Sinn Mac Addressen mit der config zu exportieren. Mac Addressen sollten unique sein und nicht mehrfach vergeben werden. Das gibt zumindest in ipv4 nur Ärger

[Jirka]

Aha. Das Monitoring macht somit einen Scan über die Interfaces (in der Standard-MIB), selbst wenn sie nicht genutzt oder gemonitort werden, und sieht so die gleiche Schnittstelle nochmal und schließt daraus, dass es ein und dasselbe Gerät ist, verstehe. Ist bei rein physikalischen Schnittstellen sicher ein guter Ansatz, aber bei dieser hier läuft man damit dann offensichtlich in ein Problem. Hmm, danke für die Info.

[sw2090]

wir haben bis zu 6 R884VA pro Standort und das bei 21 Standorten. Da noch nicht alle Standorte vollständig umgerüstet sind und manche auch kleiner sind dürften das aktuell um die 100 Stück sein. Dann doch eher Script bauen
Und für die nächsten vorher aus der XML löschen

Danke für die Hinweise!

[Jirka]

Ich frage mich eher nach dem Sinn Mac Addressen mit der config zu exportieren. Mac Addressen sollten unique sein und nicht mehrfach vergeben werden. Das gibt zumindest in ipv4 nur Ärger

Das hatte ich eben noch nicht gesehen...
Nun ja, hier ist die MAC-Adresse aber konfigurierbar und damit muss sie auch mit der Config exportiert werden. Und bei dieser Schnittstelle braucht man halt unter Umständen zwei unterschiedliche MAC-Adressen (ein Gerät hat im Auslieferungszustand nur eine MAC-Adresse). Wie schon geschrieben reden wir hier ja nicht über eine physikalische Schnittstelle, sondern eher über eine logische (jedenfalls noch an der Stelle, wo die MAC-Adresse da definiert wird). Und damit ist die MAC-Adresse dort nichts ans Gerät gebunden. [Klar hätte LANCOM alle Geräte jetzt mit 2 MAC-Adressen (oder je nach Gerät noch mehr) ausliefern können, aber dann hätte man noch ein Problem mit älteren Bestandsgeräten, insofern ist das doch ein guter Kompromiss.]

Mit einem readscript (vom ersten original konfiguriertem Gerät) wäre das übrigens nicht passiert...

Viele Grüße,
Jirka

[sw2090]

ja das sind zwei virtuelle (logische) Interfaces im Lancom richtig.
Meiner Meinung nach macht es keinen Sinn die konfigurierbar zu haben. Mac Spoofing im LACP braucht doch keiner
LCOS sollte die einfach vergeben und gut. Und dann müssen die auch nicht exportiert werden
Ist für mich irgendwie kontraproduktiv an dieser Stelle...

[alf29]

Moin,

ja das sind zwei virtuelle (logische) Interfaces im Lancom richtig.
Meiner Meinung nach macht es keinen Sinn die konfigurierbar zu haben. Mac Spoofing im LACP braucht doch keiner
LCOS sollte die einfach vergeben und gut. Und dann müssen die auch nicht exportiert werden
Ist für mich irgendwie kontraproduktiv an dieser Stelle...

Die Adresse muß konfigurierbar sein, vielleicht nicht für LACP, aber für PRP, was auf anderen LCOS-Geräten auch in diesem Bündelungs-Layer angeboten wird. Das wird in den MIBs für PRP einfach gefordert, egal ob's sinnvoll ist oder nicht.

Verstehe ich das richtig, daß es sich darum dreht, daß an dieser Stelle ein geräteabhängiger Konfig-Default steht? Das ließe sich so lösen, daß dort stattdessen als Default eine 00:00:00:00:00:00 steht (was als Sonderwert interpretiert wird, die MAC-Adresse aus dem Sysinfo zu nehmen). Wie gesagt, wenn's nur darum geht...

Viele Grüße

Alfred

[sw2090]

Das Problem ist konkret dass die Mac dieser beiden Interfaces mit der config exportiert wird. Wenn man das nicht weiss dann überschreibt man wenn man diese Config auf weiteren baugleichen Lancoms wieder einspielt (ich mache das so weil 98% meiner config auf allen unseren Lancoms gleich ist) die vorhandene von LCOS im Factory Default vergebene Mac auf diesen beiden Interfaces. Damit haben dann alle so konfigurierten Lancoms auf diesen Interfaces die gleiche Mac. Technisch gesehen tut das warscheinlich in den allerwenigsten Fällen weh. Wir verwenden kein Trunking auf unseren Lancoms also wär das technisch gesehen irrelevant. Aber: leider hängt sich nagios/icinga an die Interfaces und wenn dann zwei Lancoms auf den selben Interfaces die selbe Mac haben (auch wenn die noch drölf andere logische wie physikalische Interfaces mit unterschiedlichen Macs haben) dann überschreibt nagios/icinga das Asset wieder wenn man einen neuen Lancom als Asset scanned.

Ich habe somit jetzt an die 100 Lancoms die auf diesen beiden Interfaces die selbe Mac haben...

[alf29]

Moin,

Aber: leider hängt sich nagios/icinga an die Interfaces und wenn dann zwei Lancoms auf den selben Interfaces die selbe Mac haben (auch wenn die noch drölf andere logische wie physikalische Interfaces mit unterschiedlichen Macs haben) dann überschreibt nagios/icinga das Asset wieder wenn man einen neuen Lancom als Asset scanned.

Du meinst die MAC-Adressen, die er per SNMP und Interface-MIB aus dem Gerät lesen kann? Die wären nach so einem Umbau dann wieder für jedes Gerät andere, nämlich die, die auf dem jeweiligen Gerät LAN-1... haben.

Viele Grüße

Alfred

[Jirka]

Na ja, aber wo ist jetzt das Problem? Ich kann nachvollziehen, dass Du es nicht gewusst hast und dass dadurch jetzt ein gewisser Arbeitsaufwand entstanden ist, aber das Script erstellen und auf die 100 Geräte spielen ist in deutlich weniger als 5 Minuten erledigt, hier stand doch nun alles da, da braucht man also nur noch eine Datei erstellen, den Befehl reinzukopieren, Enter für den Zeilensprung zu drücken und das Ganze abzuspeichern und einzuspielen, fertig.
Und zukünftig nimmst die Sachen eben aus der Konfig raus, dann werden sie durch den Default ersetzt, oder gibst, wie Alfred geschrieben hat, die 00:00:00:00:00:00 an.
Der Konfigurationspunkt (den ich oben angegeben habe) ist bei einem R884VA zumindest bei mir in LANconfig gar nicht vorhanden, vermutlich war das so gewünscht seitens Telekom? Oder es ist ein Bug, dass in der Gerätebeschreibungsdatei für LANconfig dieser Punkt fehlt, das ist auch möglich. Wie auch immer kann man im Zweifel die Config ja auch manuell editieren.
Dass Nagios/icinga so reagiert, da kann ja jetzt auch keiner was dafür, ich meine soche Probleme gibt es doch zuhauf in der IT. Aber das hier ist fix abstellbar und alles ist gut...
Ich kenne das Grundproblem aus der Übernahme der Default-WLAN-Passphrases, die auch gerätespezifisch sind und so auch in der Konfig landen.

Viele Grüße,
Jirka

[alf29]

Und zukünftig nimmst die Sachen eben aus der Konfig raus, dann werden sie durch den Default ersetzt, oder gibst, wie Alfred geschrieben hat, die 00:00:00:00:00:00 an.

Das ist momentan noch eine Idee und nicht umgesetzt.

Ich kenne das Grundproblem aus der Übernahme der Default-WLAN-Passphrases, die auch gerätespezifisch sind und so auch in der Konfig landen.

Die haben wir ja jetzt auch durch einen Leerstring im Default ersetzt (was dazu führt, daß die SSID nicht in Betrieb geht, wenn man keine Passphrase selber setzt). So ein geräteabhängiger Konfig-Default ist auch ein Problem, wenn man im LANconfig eine Offline-Konfig erzeugt.

Viele Grüße

Alfred

[sw2090]

Ja so wie Jirka sagte werde ich es auch machen.
Ich bin auch der Meinung dass das ein Bug oder Fail-By-Design ist, allerdings nicht in icinga (mein Fehler ) sondern im Lansweeper.
Im Icinga lassen sich die Dinger einwandfrei erfassen. Der Lansweeper macht die Probleme...