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.
Gerade in größeren Unternehmensnetzwerken besteht die Notwendigkeit, dass Router oder Switches neben dem normalen In-Band Zugriff auch per seriellem Out Of Band Management bedient werden können, um im Störfall noch handlungsfähig zu sein.
Auf dem Markt existieren sehr viele sehr gute Lösungen, aber für den wirklich kleinen Geldbeutel ist in der Regel sehr wenig Gutes geboten – gerade wenn man auf Betriebssicherheit und „Frickelvermeidung(tm)“ Wert legt.
Dieser Artikel beschreibt ein konkretes Kundenprojekt, welches die Anforderung hatte, für möglichst wenig Budget, monatliche Mehrkosten und Komplexität einen sicheren Zugriff auf die seriellen Consolen von redundanten WAN-Routern zu ermöglichen.
Juniper stellt mit seiner „Branch SRX“ Serie für den normalen und gehobenen Mittelstand eine sehr flexible und auch preissensitive Plattform für Firewalling, VPN und Routing bereit.
Durch den sogenannten „Chassis Cluster“ besteht die Möglichkeit Hochverfügbarkeit zum administrativen Aufwand eines Einzelsystems zu bekommen, indem man zwei Firewalls zu einer logischen kombiniert.
Soweit die Theorie und auch die Praxis, wenn man sich genau an die entsprechenden KB-Artikel halten kann. Spannend wird es, wenn Anforderungen wie z.B. das Aufteilen des Clusters auf zwei Rechenzentren ins Spiel kommen.
Weiterlesen
Seit Anfang des Jahres gibt es nun von Juniper Networks offiziell eine SRX Firewall als virtuelle Maschine unter dem toll klingenden Namen Firefly Perimeter. Diese virtuelle Maschine, welche man per OVA (Open Virtualisation Archive) einfach deployen kann, hat es ziemlich in sich, da man damit sehr flexibel agieren und sehr viel Blech beim Kunden oder auch im Labor einsparen kann.
Gerade im Bereich Datacenter Switching ist inzwischen allseits bekannt, dass neben den Portgeschwindigkeiten (1,10,40,100 GBit/s) und der Oversubscription-Ratio (Idealerweise keine) auch die Latenz eine essentielle Rolle bei Performancebetrachtungen spielt.
Früher waren niedrige Latenzen bekannterweise ein Monopol für die FibreChannel-Fraktion. Ethernet wurde damals bestenfalls müde belächelt oder als Kinderspielzeug abgetan.
Heute kann jeder „normale“ Datacenter Switch FCoE und hat mit nativem FibreChannel vergleichbare Latenzen. Dabei unterbieten sich die Hersteller in immer wahnwitziger anmutenden Latenzen im Submikrosekundenbereich.
Erstaunlicherweise findet man jedoch fast nie Angaben zu den angewandten Methoden, welche einen nicht unerheblichen Einfluß auf das Ergebnis haben – in Einzelfällen sogar so extrem, dass man bei einem Messverfahren sogar „negative Latenzen“ erhalten kann. Zeitreisen gibt es jedoch leider nur in StarTrek.
Dieser Artikel soll hier etwas Licht ins Dunkel bringen.
Da wir uns aufgrund einer Kundenanfrage tiefer mit dem realen Stromverbrauch von IT-Equipment (konkret Juniper Switches) beschäftigen mussten, dachten wir uns, dass es vielleicht noch mehr Leute gibt, welche die dabei gewonnenen Erkenntnisse benötigen können.
Daher ist dieser Blog-Artikel entstanden, der sich – relativ hemdsärmelig – mit dem Energiehunger von Juniper Geräten beschäftigt.
Heute möchten wir Sie an ein etwas fortgeschrittenes Thema heranführen: BGP Route Reflection. Wir erklären, warum man so etwas braucht, wann man es idealerweise einsetzt, welche Devices man dazu verwenden kann und wie man diese konfiguriert. Dieser Artikel richtet sich an halbwegs erfahrene oder interessierte Netzwerker, die schon mit dem Border Gateway Protocol in Berührung gekommen sind, aber bisher noch nie einen Route Reflector brauchten – oder einfach nicht wussten, dass sie einen gebrauchten können.
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.
Proact Deutschland GmbH
Südwestpark 43
90449 Nürnberg
Mail: info@proact.de
Tel.: 0911 309990