SNMP ist für viele Network Management Systeme (NMS) die essentielle und oftmals einzige Schnittstelle. Durch die Vielzahl von Informationen die man über SNMP auslesen kann, ist es in der Praxis oftmals der Fall, dass die Performance (Antwortzeiten, Laufzeit eines Abfragezyklus) zu wünschen übrig lässt. Dieser Artikel beschreibt wie man unter JunOS Abhilfe schaffen kann und welche Dinge grundsätzlich zu beachten sind.
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
Kennen Sie eigentlich schon den N-IX? Der N-IX (Nürnberger Internet eXchange) ist die effektivste Datendrehscheibe in der Region Mittelfranken. Auf dieser Plattform können Datenpakete und andere hochbitratige Datendienste schnell und kostengünstig verteilt werden. Dies macht den N-IX vor allen Dingen interessant für Carrier, Internet Provider und Firmen, die mit Datennetzen arbeiten und ihren regionalen Datentransfer optimieren möchten.
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.
Power over Ethernet – kurz PoE – ist in aller Munde, besser gesagt in aller Netzwerke, da es sehr hilfreich dabei ist, bei vielen Endgeräten eine externe Stromversorgung überflüssig zu machen und somit Kosten und Aufwand zu sparen.
Dieser Artikel soll einen Überblick über alle Standards geben, die wichtigsten Grundlagen bzw. Eckdaten erläutern und im Anschluss daran Informationen über die Umsetzung bei Juniper Networks JunOS geben.
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 wollen wir wie versprochen über die Konfiguration von ECMP (Equal Cost Multipath) mit JunOS berichten. Nach ein paar Worten zu den Grundlagen holen wir uns zur Demonstration zwei bzw. drei vSRX (aka Firefly Perimeter) ins Labor und schauen uns die Praxis und die entsprechende JunOS-Syntax an.
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.
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.
Die Konfiguration eines VDSL auf einer SRX (in dem Fall SRX110 auf dem DSL-Port) kann etwas tricky sein. Beiliegend ein Konfigschnippsel einer funktionierenden Konfiguration.
Das wichtigste ist, dass die Telekom den Nutzdaten-Traffic auf dem VDSL in ein VLan verpackt. Dies ist der Fall, um Entertain Traffic (sprich: TV) sauber zu trennen und ggf. den Traffic mit QOS bearbeiten zu können. Die Telekom verwendet VLan 7 – andere Carrier könn(t)en anderen VLans verwenden. Ausserdem wird die Telekom kein PAP akzeptieren, sondern die Authentifikation muss über CHAP erfolgen. Letztlich zu beachten gilt, dass die Telekom nach 3 erfolglosen Authentifikationen den DSL-Nutzer für 24h sperrt. Eine Entsperrung kann über ein Fax erfolgen oder in dem man den Business-Anschluss über das Kundenportal auf eine feste IP umstellt.
Weiterlesen
Proact Deutschland GmbH
Südwestpark 43
90449 Nürnberg
Mail: info@proact.de
Tel.: 0911 309990