Karsten's weblog - Netzwerk

Höchste Präzision in der LWL Technik aus der Schweiz

nospam@example.com (Karsten) — Sun, 17 Jun 2007 08:38:31 +0200

In den vergangenen Tagen hatte ich die Möglichkeit einer der führenden Hersteller von LWL [1] Verbindungen zu besichtigen. Die Firma Diamond [1] ist in Losone im schönen Tessin zu Hause. Die Firma ist unter anderem für Ihre Präzisionsstecksysteme und dem heute oft eingesetzten E2000 System bekannt. Die Entwicklung des E2000 Systems geschah zum grössten Teil in Losone.

Vor dem Besuch war mir die Technik, welche hinter der Produktion und Montage von LWL-Steckern steckt gar nicht bewusst. In der Mechanik sind schon Toleranzen von mico m kaum zu erreichen. In der LWL Technik wird von nano m gesprochen. Für mich ist dies sehr faszinierend und zugleich nur schwer vorstellbar.

An dieser Stelle möchte ich mich bei der Firma Diamond für den herzlichen und sehr informativen Empfang bedanken.

[1]: http://de.wikipedia.org/wiki/Lichtwellenleiter

[2]: http://www.diamond-fo.com

VTP

nospam@example.com (Karsten) — Thu, 22 Feb 2007 18:47:21 +0100

VTP steht für VLAN Trunking Protocol und ist Cisco proprietär. Das Protokoll erlaubt das zentrale definieren von VLAN’s und das automatische verteilen auf die entsprechenden Client-Switchs. Prinzipiell sind auf den Cisco Netzwerk-Komponenten welche 802.1q / x tauglich sind drei verschiedene VTP-Modis verfügbar.
Client: Das Gerät bezieht die VLAN Definitionen von der angegebenen VTP-Domain (Server)
Transparent: Lokale Definition der VLAN’s
Server: Gerät agiert als VTP-Server.

Ich möchte mich in diesem Blogeintrag den Möglichkeiten von VTP widmen. Prinzipiell gibt es zuerst einige Dinge zu wissen, so wird VTP aktuell nur über Layer 2 transportiert. Nach meiner Ansicht ist dies in gewissen Situationen tatsächlich ein Manko. Jeder VTP-Client wird in eine VTP-Domain integriert. Solange keine doppelt vergebenen VTP-Domain Namen vorhanden sind, ist dies unproblematisch. Spielen wir ein Szenario durch, eine Person X mit schlechten absichten Steckt eine Cisco 3750 Switch ans LAN. Es greifen keine Schutzmechanismen wie z.B. BDPU Guard oder 802.1x Authentication. Kurz gesagt ist das Netzwerk vor intern unbefugten Zugriffen nicht geschützt. Er konfiguriert seine Switch als VTP-Server mit einem identischen Domain-Namen. Prinzipiell kann er somit Durcheinander stiften. Natürlich ist VTP selbst auch von Sicherheitslücken betroffen, in der heutigen Zeit ist dies jedoch nichts Ungewöhnliches. [1] Leider kenne ich bis jetzt noch keine Alternativen für VTP mit denselben Funktionen. Ich lasse mich jedoch gerne besserem belehren.

[1]:http://www.cisco.com/en/US/customer/products/products_security_response09186a00807d1a81.html

Cisco IOS Upgrade

nospam@example.com (Karsten) — Sat, 03 Feb 2007 13:55:52 +0100

Fast täglich werden in den Forschungslaboren von Cisco und deren Partner neue Bug in den IOS Versionen entdeckt. Viele Bugs dringen gar nicht bis zu den Endanwendern vor, sie werden als intern gehandhabt. Auf Anfrage sind teilweise unoffizielle Patch-Tools vorhanden. Andere Bugs z.B. Sicherheitslücken werden teilweise veröffentlich und von Cisco in einer neuen IOS Version oder Patch behoben. Vorübergeben werden Worksarounds angeboten, welche das Problem temporär umgehen. Oftmals sind diese bei grösseren Umgebungen mit viel Aufwand verbunden.
Im Urwald der Versionsnummern (12.2(25)SE, 12.2(25)SEE, usw.) sieht niemand mehr durch. Nur die Spezialisten wissen, was welcher Buchstabe genau zu bedeuten hat. Die Change-Reports von der einen zur nächsten Version sind schnell mehrere Seiten lang, und helfen nicht immer weiter. In grösseren Umgebungen ist das Upgrade aller Cisco Gerät meistens eine zeitintensive Arbeit. Der Netzwerkadministrator muss entscheiden, wann ein Update eingespielt werden soll. Das Prinzip „never touch a running system“ gilt auch bei Netzwerk-Komponenten. Sicherheitslücken machen jedoch irgendwann ein Upgrade der Netzwerkinfrastruktur notwendig. Wie wird bei einem Upgrade der gesamten Infrastruktur am besten vorgegangen? Erstmal sollte nicht einfach die neue Version aufgespielt werden. Das Testen in einer Testumgebung ist unerlässlich. Oftmals stehen externe Spezialisten wie z.B. Cisco Gold Partner zur Verfügung, sie können Hilfestellung leisten. Nach dem erfolgreichen Test, können Tools wie z.B. das Cisco LMS bzw. der Campus Manager Arbeit abnehmen. So kann z.B. in der Nacht ein Job zum Upgrade der entsprechenden Komponenten eingeplant werden. Es werden Optionen geboten wie z.B. Roll-Back wenn das Upgrade aus irgendeinem Grund fehlgeschlagen ist. Prinzipiell werden noch einige Features mehr geboten wie z.B. das Gerät soll noch nicht gebootet werden usw. Normalerweise bin ich kein Freund von automatisierten Prozessen, bei Grossumgebungen macht dies jedoch durchaus Sinn.

Störfaktoren bei einem WLAN

nospam@example.com (Karsten) — Fri, 12 Jan 2007 18:18:36 +0100

WLAN's gehören heute zu den modernen Kommunikationsmittel und sind längst nicht nur in privaten und kleinen Unternehmen zu finden. Das kabellose arbeiten bietet einiges an Komfort, die Sicherheitsproblematik darf jedoch nicht unterschätzt werden. Ich möchte mich in diesem Blogeintrag ein wenig mit den Störfaktoren für WLAN widmen. In Büroräumlichkeiten ist vor allem Reflexion der Strahlen problematisch. Ein Aufhängen eines Access Points in unmittelbarer Nähe von Glasflächen kann zu Problemen führen. Auch bei Industriebetrieben sind unterdessen kabellose Netzwerke vorhanden. Hallenkräne, Stahlsäulen, Metalllager und Stahlbeton gehören zu den meisten Einflussquellen. Nicht zu unterschätzen sind Hochspannungsleitungen oder Transformatoren. Jedes WLAN kann mit den entsprechenden Messgeräte ausgemessen werden, dies muss auf jeden Fall bei laufendem Betrieb der Umgebung geschehen. Das Aufbauen eines sauberen Roaming mit kompatiblen Endgeräten und natürlich mit der entsprechenden Sicherheit ist heute durchaus nicht mehr eine Unmöglichkeit.

HSRP die Lösung für alle Redundanz Probleme?

nospam@example.com (Karsten) — Sun, 17 Dec 2006 20:08:29 +0100

Viele Unternehmen funktionieren nicht mehr ohne das Funktionieren der Informatik Infrastruktur. Stellen Sie sich vor eine Bank hätte keinen Zugriff auf Ihre Kontendaten mehr. Zu einem werden Sie als Kunden verärgert zum anderen verunmöglicht dies jegliche finanziellen Transaktionen. Sie haben nicht mehr die Möglichkeit auf Ihr Geld zuzugreifen. Das Vertrauen in Ihren Finanzdienstleister ist erschüttert. Dies mag vielleicht ein eher hartes Beispiel sein, leider sind solche Situationen durchaus vorgefallen und werden auch weiterhin nicht verhindert werden können. Aufbau von redundanten Servern und Infrastrukturen ermöglichen eine hohe Verfügbarkeit von kritischen Systemen. Gerade bei Netzwerken, welche sich an die 802.1X / Q halten wird eine zusätzliche Herausforderung sichtbar. Die meisten Serversysteme erlauben nur die Eingabe eines Standardgateways, zumindest wenn eine möglichst saubere Lösung angestrebt wird. Alternativen würde z.B. dynamisches routing bieten, dies bedarf aber meistens einem hohen Administrations-Aufwand. Ich möchte mit Ihnen ein einfaches Szenario in einem modernen Netzwerk durchführen. Das Netzwerk ist in VLAN's unterteilt wie es teilweise im IEEE 802.1Q Standard definiert ist. Nehmen wir an aus einem technischen defekt verabschiedet sich der Standardgateway (Router) Ihres Server-VLAN's. Die Server sind somit von der Kommunikation vom restlichen Netzwerk abgeschlossen. Keine andere Netzwerkkomponenten aus einem anderen VLAN können auf die Server zugreifen. Dies kommt einem Ausfall der Infrastruktur gleich. Cisco entwickelte von einiger Zeit ein proprietäres Protokoll namens HSRP (Hot Standby Router Protocol). HSRP erlaubt das verschieben des Standardgateways auf einen anderen Router. Führen wir unseres Szenario fort unter der Verwendung von HSRP. In Ihrem VLAN sind zwei Router (Standardgateways) verfügbar. Aus den beiden Routern wird einen logischen Router gebildet mit einer logischen IP-Adresse und mit einer logischen MAC-Adresse. Fällt nun Ihr primärer Router aus, wird der Standardgateway (logische IP und MAC) automatisch auf den sekundären Router verschoben. Durch den Erhalt der IP und MAC Adresse ist nicht einmal ein Refresh der ARP Tabelle bei den betroffenen Clients nötigt. Ein unterbrechungsfreies Umschalten ist natürlich nicht möglich. Kann aber durch timers möglichst niedrig gehalten werden. Ich möchte an dieser Stelle auch den Grund dafür erläutern. Der sekundäre Router muss den Ausfall des primären Routers zuerst bemerken. Dies geschieht über „Hello“ Pakete. Antwortet z.B. der primäre Standardgateway auf fünf „Hello“ Pakete nicht, wird der Gateway mit einem Zusatz von einer Sekunde verschoben. Wie erwähnt können diese Zeiten mit timern beeinflusst werden. Einen zu niedrigen Schwellwert könnte jedoch das Unnötige Triggern zwischen den Routern zur Folge haben. HSRP wird von den meisten Cisco Routern und ebenfalls den Cisco Core Switchs z.B. 450x und 70xx unterstützt. Teilweise ist dieses Protokoll auch bei anderen Herstellern implementiert.

HACMP Problematik

nospam@example.com (Karsten) — Mon, 23 Oct 2006 19:51:14 +0200

HACMP steht für High Availability Cluster Multi-Processing, dieses Protokoll kommt vor allem bei IBM AIX Systemen zum Einsatz. HACMP erlaubt das Clustern von hochverfügbarkeits- Systemen. Falls an einem System Wartungsarbeiten durchgeführt werden, wird der Userrequest automatisch an das BackUp System weitergeleitet. Diese Möglichkeit ist gerade bei kritischen Vorgängen wie z.B. Abrechnungen oder Treasury unverzichtbar.
Prinzipiell werden bis zu 32 Knoten in einem Clusterverbund zugelassen. Um eine Möglichst hohe Ausfallsicherheit gewährleisten zu können, sollte das BackUp System physikalisch getrennt werden. Leider stellen sich hier einige Hürden in den Weg, welche bei einer Umsetzung von HACMP beachtet werden müssen. HACMP unterstützt kein routing (Layer 3) über andere Netzwerkgeräte. Beide Systeme müssen physikalisch mit einer Layer zwei Anbindung verbunden sein. Gerade bei moderneren Layer 3 Netzwerken muss dafür einen extra Link zur Verfügung gestellt werden. In einigen Fällen kann z.B. eine Verbindung über eine längere Distanz eine teure Angelegenheit sein. In älteren Versionen (HACMP 4.4) wie es bis AIX 5.1 eingesetzt wurde, ist auch anfällig auf eine Schwachstelle. [1]. Bei einem dediziertem HACMP Link ist diese Schwachstelle jedoch anders einzustufen.

[1]:http://nvd.nist.gov/nvd.cfm?cvename=CVE-2001-0998