Nach vielen Jahren treuer Dienste schickt Juniper einiges an bewährter Hard- und Software in den verdienten (Vor-)Ruhestand – selbstverständich nicht ohne entsprechende Nachfolgeprodukte. Die Änderungen für das Jahr 2019 im Portfolio von Juniper möchte ich in diesem Artikel auflisten.
Weiterlesen
Leider erreichen uns regelmäßig Hilferufe von Kunden, die eine Netzwerk-Störung erleiden mussten.
In vielen Fällen sind einfache Missgeschicke von Anwendern die Ursache: Es wurde unwissentlich eine Schleife gesteckt oder ein externes Gerät angesteckt, welches falsche IP-Adressen verteilt. Die Folge: Eine massive Störung im Netzwerk. Im heutigen Blog-Beitrag möchte ich erläutern, wie Sie solche Missgeschicke mit einem Syslog-Monitoring schneller feststellen oder gar vermeiden können.
Ab einer gewissen Menge von Netzwerk Devices wird die lokale Pflege von personalisierten Benutzern eine Herausforderung und Sisyphusarbeit. Daher bietet es sich an das Active Directory als zentralen Verzeichnisdienst zu nutzen – auch für Netzwerk Geräte. In meinem heutigen Blog Artikel möchte ich eine einfache Alternative zur lokalen Userverwaltung vorstellen: Die Radius- bzw. AD-basierte Authentifizierung.
Obwohl das neue Jahr nur wenige Tage alt ist, hatte es mit Meltdown und Spectre bereits einiges an sicherheitsrelevanten Bugs im Petto.
Auch in Juniper Produkten wurde jetzt eine schwerwiegende Sicherheitslücke entdeckt.
Immerhin ist der Workarround im Gegensatz zu Meltdown und Spectre einfach: Auf den betroffenen Geräten muss das Web-Management deaktiviert werden.
MACSec oder IEEE 802.1AE ist ein Protokoll, welches die verbindungslose Sicherstellung von Datenvertraulichkeit und Datenintegrität auf Media-Access-Control-(MAC) Ebene definiert bzw. standardisiert. Ebenso ist ein Wiederholungsschutz (replay-protection) und Schlüsseltauschprotokoll (perfect-forward-secrecy) mit definiert.
Seit JunOS 15.1X49-D100 ist MACSec offiziell auf den SRX3xx Branch Firewalls von Juniper unterstützt. Da inzwischen 15.1X49-D120 released wurde ist es an der Zeit mal einen halbwegs praxisnahen Test zu starten um zu sehen was die 300er SRX-Series denn mit MACSec so können, da einige Aspekte von MACSec im Vergleich zu IPSec oder anderen „secure tunnels“ allgemein oder speziell bei Juniper SRX interessant sind.
Im September 2010 wurde IEEE 802.3az als ein Standard für ein energieffizienteres Ethernet veröffentlicht, welcher von vielen Herstellern, schon vorab als Green Ethernet vermarktet wurde. Ziel sollte sein 50% oder mehr an Energie pro Ethernet Port einzusparen und das unter Berücksichtigung von Abwärtskompatibilität und keinerlei Beeinträchtigungen der Betriebsstablilität.
Die besinnliche Zeit um die Jahreswende und durch aktuelle Wetter und Klimaereignisse in der Realität und Politik gaben den initialen Gedankenanstoß sich mal damit zu beschäftigen ob denn 802.3az das Zeug dazu hat einen kleinen Betrag dazu zu leisten den Energieverbrauch und damit die CO2-Emissionen ein klein wenig zu reduzieren.
Ob und wie viel es bringt erfahrt Ihr in diesem „Aus den teamix Labs“ Blog Artikel.
In der Überschrift steht zwar schon das Ergebnis, aber diesmal wollen wir euch mal einen Blick hinter die Kulissen von teamix gewähren, was so eine profane Überschrift an Arbeit nach sich zieht.
Vorgeschichte: Bei teamix hat es sich zur Trandition entwickelt, dass selbst wenn wir wegen Kindern oder Weihnachts-Anti-IT-Blues nicht mehr so zahlreich auf dem Congress vertreten sind zumindest dafür zu sorgen, dass die Jungs ein halbwegs solides LAN und WAN haben. Darum kümmern wir uns immer rechtzeitig mit den Organisatoren vom CCC darum, dass ausreichende Mengen an Leihequippment von Juniper bereit gestellt werden. Weiterlesen
Irgendwann trifft jeder auf einen Wert den ein show Kommando seines Routers oder Switches zurück liefert, der einfach nicht per SNMP zu bekommen ist. Als praktisches Beispiel nehmen wir hier die Werte von „show interfaces diagnostics optics“. Wir wollen euch heute einen praktischen Weg aufzeigen wie ihr beliebige Werte aus Junos per SNMP abrufbar macht.
Hat man die Aufgabe eine größere Menge (>10) an SRX Firewalls auszurollen, ist es sinnvoll sich vorher kurz Gedanken zu machen, wie man dies automatisiert und standardisiert bewerkstelligen kann. Das spart neben Zeit auch noch Nerven und viele mögliche Fehlerquellen.
Darum wollen wir euch heute zeigen welche Mittel Juniper uns da an die Hand gibt.
Hi @all,
heute Nacht ist es soweit: Wir erhalten eine zusätzliche Sekunde bzw. eine sog. Schaltsekunde (= Leap Second). Was heisst das? Die Zeit könnte je nach System/OS/Applikation auf eine Uhrzeit von 23:59:60 UTC (01:59:60 Uhr CEST) springen. Die letzte Schaltsekunde gab es im Jahr 2012.
Das Problem: Gewisse Systeme haben diesen Fall bereits bedacht, andere Systeme nicht. Die Auswirkungen unterscheiden sich je System und reichen von: „nicht betroffen“ über „100% CPU Last“ bis hin zu „Absturz des Systems“.
In diesem Blogartikel findet ihr eine gesammelte Liste mit Links, in der die nicht-betroffenen und betroffenen Systeme aufgelistet sind. Bitte prüft eure kritischen Systeme, ob sie von der „Leap Second“ betroffen sind, verwendet umgehend die angegebenen Workarounds und prüft am Besten heute Nacht nach 00:00:00 Uhr UTC (02:00:00 Uhr CEST) direkt, ob alle Systeme noch sauber laufen. Nicht, dass morgen das „böse Erwachen“ bzw. der „große Knall“ kommt und eure User nicht arbeiten können…
Hier die gesammelte Liste der Fa. teamix GmbH mit den Links bzgl. dem Thema „Leap Second“:
Proact Deutschland GmbH
Südwestpark 43
90449 Nürnberg
Mail: info@proact.de
Tel.: 0911 309990