Zugschlusbeobachtungen (Entries tagged as ethernet)

Quality of Service im Ethernet fuer Telefonieanwendungen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 27 Jun 2008 10:31:38 +0200

Schon seit etwa anderthalb Jahren hat sich ein Kunde mit seinen Büroräumen auf ein anderes Gebäude ausgedehnt. Zwischen den beiden Gebäuden gibt es zwar Glasfaser, aber keine Kupferverkabelung. Trotzdem möchte man auch im neuen Büro gerne telefonieren können; dort sollen Nebenstellen der am alten Ort vorhandenen Alcatel OmniPCX Enterprise aufgestellt werden.

Daraus entsteht die logische Entscheidung, die Telefone im neu hinzugekommenen Bereich des Gebäudes per IP anzubinden: Das geht nämlich über die vorhandenen Glasfasern, während man für digitale Endgeräte an der TK-Anlage entweder Kupfer werfen, oder den neuen Standort mit einem (teuren!) Gateway zum Umsetzen von IP auf die digitalen Endgeräte ausstatten müsste.

Also bietet sich die Möglichkeit, ein bisschen über IP-Telefonanlagen in überlasteten Netzen zu lernen.

Da der neue Standort mit relativ sportlichem Zeitplan produktiv werden soll, und der TK-Anlagen-Lieferant am liebsten seine eigenen Switche verkauft anstelle seinen Kunden bei der Konfiguration fremdgelieferter Switche zu helfen, wird zunächst für die Telefonie eine getrennte Infrastruktur aufgebaut: Neben dem Gigabit-Link für das Datennetz wird auf einem zweiten Fasernpaar mit Hilfe von Medienwandlern und einem uralten HP4000M eine zweite Verbindung zwischen den beiden Gebäuden realisiert, die ausschließlich für die Telefonie genutzt wird. Im alten Standort kommen zwar beide Links auf demselben Switch und demselben VLAN raus, aber in dieser Konfiguration ist wenigstens sichergestellt, dass das Datennetz nicht die Telefonie behindern kann (es sei denn, man überlastet die Backplane des Switches, auf dem die beiden Links in den neuen Standort ankommen und an den auch die TK-Anlage angeschlossen ist).

Das hat jetzt anderthalb Jahre lang prima funktioniert. Nun soll der alte HP4000 weg und durch einen moderneren Switch ersetzt werden, und bei der Gelegenheit hätte man gerne auch gleich etwas Redundanz, Ring und Spanning Tree. Und ich spiele ein wenig mit der IP-Telefonie und versuche, etwas über ihr Verhalten auf einem überlasteten Netz zu lernen.

Leider hat der Kunde keine Reserve-TK-Anlage, was mich dazu zwingt, die Tests mit der produktiven Anlage zu machen und sicherzustellen, dass meine Tests den Produktivbetrieb des Kunden nicht behindern. Also nehme ich mir einen Stapel Switche unter den Arm und fahre hin.

Zeichnung des Testlabs

Das Bild zeigt mein Testlab, das mit dem produktiven Officenetzswitch des Kunden und der TK-Anlage auch Infrastruktur umfasst, die besser nicht ausfallen sollte. Mein Testclient A kommt neben die TK-Anlage; über einen dot1q-Trunk Gigabit Ethernet verbinde ich meinen Test-Switch 1 mit der Infrastruktur des Kunden. Mein Testclient B kommt an Test-Switch 1. Test-Switch 2 mit Testclient C und einem Alcatel-IP-Telefon wird über einen dot1q-Trunk mit Test-Switch 1 verbunden. Der Trunk zwischen Test-Switch 1 und Test-Switch 2 wird beidseitig auf 10 Mbit Fullduplex geschaltet, um es später bei der Simulation eines überlasteten Netzes einfacher zu haben. Alle anderen Links im Spiel sind Fast Ethernet.

Das Test-Setup funktioniert: Alle Testclients sehen einander, die TK-Anlage und das Telefon; das Telefon bucht sich sauber in die TK-Anlage ein und ich kann telefonieren. Als Testgesprächspartner dient zunächst die unter einer normalen Baden-Badener Ortsrufnummer erreichbare SWR3-Stauhotline, die den Vorteil hat, dass ein Automat einen geduldig minutenlang vollsabbelt und man auf diese Weise prima entscheiden kann, ob das Telefonat noch ordentlich funktioniert oder nicht.

Die Alcatel-Anlage benutzt für die Kommunikation mit ihren IP-Telefonen ein Wireshark nicht weiter bekanntes, auf UDP aufsetzendes Protokoll, das sich weder als SIP noch als H.323 identifizieren lässt. Wird also mit einiger Wahrscheinlichkeit leider etwas proprietäres sein. Oder ich habe nur den richtigen Standard nicht gefunden. Das schöne an Standards ist dass es so viele davon gibt.

Test A0: Testclients A und B tauschen bidirektional über TCP und netcat Daten von /dev/zero nach /dev/null aus. Dabei beschränkt sichTCP selbsttätig auf die Dicke des künstlichen Flaschenhalses zwischen den beiden Test-Switches, und auch das Telefon interessiert sich nicht großartig dafür, dass das Netz gut ausgelastet ist. Das sieht man auch wunderschön im torrus-Plot des Swichports, dessen Auslastung zwar nur knapp, aber doch sichtbar unter 10 Mbit/s bleibt. Auch ohne auf den Switchen konfigurierte Priorisierungsmechanismen funktioniert das Telefon prima und ich muss mir etwas anderes einfallen lassen, um einen Fehler zu erzeugen. Also nehmen wir für die weiteren Tests UDP, das keine ins Protokoll verankerten Durchsatzregelmechanismen hat. Die Wahl zur Erzeugung der Testdaten fällt schnell auf das Paket netperf.

Test A1: Während eines laufenden Telefonats beginne ich, mit netperf massenhaft UDP-Pakete von Testclient C zu Testclient B zu übertragen. Die Netzlast ist also dem Datenstrom, dessen Qualität ich als einziger menschlicher Teilnehmer des Telefonats beurteilen kann, entgegengesetzt. Beim Start der Netzlast verschlechtert sich die Qualität des Telefonats nicht; man hört keine Störungen.

Test B1: Dasselbe, nur andersrum. Diesmal fließen die Netzlastdaten in dieselbe Richtung wie die relevante Richtung des Telefonats, und man bemerkt sofort nach dem Start der Netzlast erhebliche Aussetzer in der Telefonie, als der Switch in seiner Verzweiflung auch massenhaft zum Telefonat gehörende Datagramme verwirft weil sie beim besten Willen nicht mehr auf den saturierten 10-Mbit-Link passen. Nach etwa 30 Sekunden hat das Telefon genug und bootet.

Test A2: Im Setup von Test A1 wird der Flaschenhals entschärft, indem der Link zwischen den beiden Testswitches auf 100 Mbit konfiguriert wird (mehr als 100 Mbit kann mein Test-Switch 2 nicht). Da es auch schon mit 10 Mbit/s funktioniert hat, erstaunt wenig, dass das Testergebnis auch bei einem 100-Mbit-Link zwischen den beiden Testswitches “funktioniert” lautet.

Test B2: Dasselbe wie Test B1, nur mit einem 100-Mbit-Link zwischen den beiden Switches. Auch hier hört man sofort nach Start der Netzlast Störungen, jedoch deutlich weniger als bei Test B1. Auch hier wirft das Telefon nach einiger Zeit (diesmal deutlich länger, einige Minuten) das Handtuch und bootet.

Test A3: Nun führen wir den künstlichen Flaschenhals wieder ein und beschränken die Bitrate auf dem Link zwischen den beiden Testswitches wieder auf 10 Mbit/s. Als Ausgleich dafür erhalten die Switchports, auf denen die TK-Anlage und das Telefon hängt, die Konfigurationsoption “qos priority 4”. Die Wirkung bei der Wiederholung von Test A1 auf diesem Setup ist evident, auch bei Betrieb der Lastgeneratoren bleibt ein Telefonat unbeeinflusst. Dies wird auch bei einem längeren Telefonat zwischen Menschen bestätigt; beide Gesprächspartner bemerken keinen Unterschied in der Gesprächsqualität beim Hinzuschalten der Netzlast. Während des etwa zehnminütigen Tests bleibt das Telefon stets eingebucht und benutzbar.

Der Vollständigkeit halber gibt es dann auch noch Test B3, der Test B1 bei konfiguriertem “qos priority 4” wiederholt, mit denselben Ergebnissen wie Test A3.

Diese Testreihe ist aus dem Mai 2008. Bei der ersten Durchführung der Tests im Sommer 2007 hat sich die Anlage noch signifikant anders verhalten: 2007 buchte sich das IP-Telefon bei fast allen Tests, auch bei den Tests mit auf den Switchen aktiviertem QoS trotz qualitativ nicht eingeschränkter Telefonieverbindung nach einigen Sekunden Netzlast aus der Anlage aus und bootete. Im Frühjahr 2008 erhielt die TK-Anlage eine Runderneuerung und auch eine neue Software, was die spontanen Ausbucher der IP-Telefone drastisch verringert hat. Wie oben gezeigt, fliegen die IP-Telefone mit der derzeitigen Software auf der Anlage nur in Situationen weg, wo sie das auch dürfen.

Technisch habe ich das ganze jetzt so verstanden: Durch das Setzen von “qos priority 4” erhalten die über einen so konfigurierten Port empfangenen Ethernet-Frames eine höhere Priorität als die über einen “normalen” Port empfangenen Frames und werden somit bevorzugt innerhalb des Switches weitergeleitet. Bei der Übertragung des Frames über einen dot1q-Trunk wird die Priorisierung des Frames wohl im VLAN-Tag mit transportiert und bleibt somit bis zum Egress-Port und dem Zielendgerät enthalten. Somit ist es möglich, im gleichen VLAN priorisierte und nicht priorisierte Frames zu transportieren, was gegenüber einer VLAN-Priorisierung (die wohl auch irgendwie geht) praktisch ist, wenn in einer gewachsenen Infrastruktur TK-Endgeräte und nicht-TK-Endgeräte im gleichen VLAN leben und man den Traffic von TK-Endgeräten trotzdem priorisieren muss.

Ein Nachteil besteht darin, dass man die Access-Ports der Switche zum Endgerätetyp passend konfigurieren muss und dass ein versehentlich an einem priorisierten TK-Port angeschlossenes Datenendgerät bei hinreichend bösem Willen die Telefonie sabotieren kann. Das lässt sich aber bei dem Schicht-2-QoS, um das es hier im Artikel geht, kaum verhindern. Es sei denn, man macht dot1q bis zum Endgerät, damit das Endgerät seinen Priorisierungswunsch gleich ins VLAN-Tag schreiben kann. Aber das öffnet eine ganz andere Problemklasse aus dem Bereich Security, was ich gerne vermieden habe.

Andere QoS-Verfahren setzen die Priorität aufgrund von “höheren” Protokollinformationen wie Absender- oder Empfänger-IP-Adresse oder TCP/UDP-Portnummern und bilden die so ermittelte Priorität auf die Priorätit des schließlich zu transportierenden Ethernet-Frames ab. Dazu brauchen die Switches aber IP-Intelligenz (“Layer 3 Switches”), was die vorhandenen Switche nur sehr unbefriedigend beherrschen und was ein größeres Netzredesign erzwingt. Das werden wir im konkreten Fall besser beiben lassen.

Fazit: Die Alcatel-IP-Telefonie ist nun auch auf einer gemeinsam mit Datendiensten genutzten Netzwerkplattform nutzbar, weil durch geeignete Konfiguration der Switches sichergestellt werden kann, dass der Einfluss von Datenanwendungen auf die Telefonie minimal ist.

Weiterer Lerninhalt: Es ist verdammt schwer, mit üblichen Protokollen in heutigen LANs eine Lastsituation zu erzeugen, die von zeitkritischen Anwendungen wie Telefonie überhaupt bemerkt werden. Besonders TCP ist da extrem gutmütig und nimmt seinen Datendurchsatz automatisch so weit zurück, dass andere Anwendungen auf derselben Physik nicht signifikant bemerken, dass da eine TCP-Anwendung das Netz füllt. Ich würde erwarten, dass in einem nicht priorisierten LAN der Start einer weiteren TCP-Anwendung in der Praxis keine Auswirkung auf die Telefonie hat. Höchstens bei vielen TCP-Verbindungen würde ich erwarten, dass das Telefonat einmal kurz aussetzt bis die beteiligten TCP-Stacks einander bemerkt haben und ihren Durchsatz entsprechend reduziert haben. Als Problemkinder bleiben also nur Protokolle wie UDP oder ESP, die keinen solchen Mechanismus haben.

Ethernet mit Link aber ohne Daten

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 22 Apr 2008 21:07:56 +0200

Nachdem U es inzwischen endlich geschafft hat, den alten DSL-Anschluß zu deaktivieren und inzwischen unsere eingehenden Telefonate auch dann auf dem Alice-Anschluß herauskommen, wenn der Anrufer aus dem Netz von U anruft, ist die technische Migration endlich geschafft. Puh.

Ich nutze die Gelegenheit, im Kabäuschen etwas Klarschiff zu machen: Altes IAD raus, den im derzeitigen Zwischenzustand ungenutzten Linksys raus, Test-Eurit und Übergangs-Anrufbeantworter raus, die damit überflüssig gewordenen vier Steckernetzteile raus, das Alice-IAD an die Wand und die Patchung etwas sauberer konstruieren. Nachdem das alles vernünftig aussieht, stellen wir fest, dass die Fritzbox nur noch PPPoE-Timeouts sieht. Eine Runde Resets hilft nicht, das Notebook kriegt auf seine PADIs auch keine Antwort, Mist.

Systematisches Debuggen zeigt dann, dass das Ethernet 4 das Alice-IAD zwar einen Link anzeigt, aber keine Daten transportiert. Mit Ethernet 3 geht’s dann. gnarf

Warum ein reines Modem an einem Produkt, das technisch auf einen PPPoE-Connect zur Zeit limitiert ist, vier Ethernet-Ports mitbringt, war mir bis heute unklar. Inzwischen weiß ich es und fühle mich gut damit, noch zwei Ethernets in Reserve zu haben, bevor ich ein neues IAD ordern muss.

Notwork Technology: Power over Ethernet

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 05 Apr 2008 22:35:00 +0200

Auf dem Papier liest sich Power over Ethernet ja ganz prima: Dezentrale Netzwerkgeräte mit geringem Strombedarf wie Wireless-LAN-Accesspoints, Netzwerkkameras, Desktop- oder Kabelkanalswitche und IP-Telefone können über das Ethernetkabel mit Strom versorgt werden. Das reduziert den Verkabelungsaufwand auf die Hälfte, weil man das Gerät nur noch mit einem Kabel anfahren muss, erlaubt die unterbrechungsfreie Stromversorgung verteilter Geräte mit einer einzigen, zentralen USV in der Nähe des Netzwerkverteilers, und als Nebeneffekt kann man die Geräte auch dann einfach powercyceln, wenn sie physikalisch schlecht zugänglich in einer abgehängten Decke montiert sind.

Die Praxis sieht leider anders aus: Das ganze ist nicht ganz billig und es gibt Inkompatibilitäten an jeder Ecke.

Zunächst erstmal etwas Theorie. Wie wir alle wissen, hat ein Cat5-Kabel vier miteinander verdrillte Adernpaare, von denen für die gängigen Standards für Ethernet (10Base-T, kurz “E”) und Fast Ethernet (100Base-TX, kurz “FE”) nur zwei als Datenpaare benutzt werden. Erst für Gigabit Ethernet (1000Base-TX, kurz “GE”) werden alle vier Adernpaare verwendet. Darauf basieren auch viele “adernsparende” Verkabelungssysteme, die auf einem Cat5-Kabel zwei ISDN- oder Ethernet-Links (tauglich nur für E und FE) transportieren, die bei Umstellung auf GE (oder PoE) dann subtil versagen und die vor fünf bis zehn Jahren in falsch verstandener Sparsamkeit in größerem Stil eingebaut wurden.

Literatur zu Power over Ethernet gibt es in homöpatischer Dosis in der Wiki pedia (bitte möglichst den englischsprachigen Artikel lesen, der taugt besser) oder auch auf www.poweroverethernet.com. Einen guten Überblick über die Technik bietet das White Paper on Power Over Ethernet (IEEE802.3af).

Der 802.3af-Standard spezifiziert den Transport von knapp 15W über 48V vom Power Sourcing Equipment (PSE) zur Powered Device (PD). Dabei kann der Strom entweder als Phantomspeisung auf den beiden Adernpaaren transportiert werden, die E und FE für ihre Daten benutzen (“Power over Data Pairs”) oder aber über die beiden in einem mit E oder FE belegten Cat5-Kabel unbenutzten Adernpaare (“Power over Spare Pairs”). Dabei ist klar, dass Power over Spare Pairs bei den oben schon erwähnten Adernsparinstallationen auf die Schnauze fällt und man bei GE unbedingt Power over Data Pairs verwenden muss. Der Standard spezifiziert, dass das PSE sich aussuchen darf, welche der beiden Methoden verwendet wird. Beide Methoden gleichzeitig dürfen aber nicht verwendet werden. Aus dem Wahlrecht der PSE folgt die Pflicht für die PD, beide Methoden zu unterstützen. Leider haben diese Pflicht noch nicht alle PD-Hersteller verinnerlicht.

PSEs gibt es am Markt in drei verschiedenen Darreichungsformen:

Endspan-PSE, üblicherweise als PoE-Switch implementiert, der sowohl Ethernetswitch als auch PSE darstellt. Diese Geräte stellen die Spannungsversorgung üblicherweise als “Power over Data Lines” bereit und können oft aufgrund der sparsam dimensionierten Netzteile nur einen Teil ihrer Ports versorgen. Um Überlastsituationen zu vermeiden, kann man für jeden Port eine Priorität setzen und somit verhindern, dass “wichtigen” PDs der Saft abgedreht wird während “unwichtige” weiterhin versorgt werden. In Installationen mit hohem Anteil an PDs (z.B. bei IP-Telefonanlagen mit eigenen Switchen) kann die Begrenzung der maximalen Versorgungsleistung schon störend werden; für ein paar Accesspoints etc in einem sonst konventionellen Netz spürt man von dieser Einschränkung in der Praxis nichts.
Midspan-PSE, auch als Power-Injektor bezeichnet.
- Multiport-Injektoren sehen aus wie ein Switch, und werden zwischen den Ethernet-Switch und die PD geschaltet. Mit solchen Geräten kann man mehrere PDs an einem Gerät angeschlossen haben. Multiport-Injektoren gibt es auch in managebar, so dass man sich angucken kann, wieviel Strom die einzelnen Geräte aufnehmen und man die Geräte auch ein- und ausschalten kann ohne wirklich an den Patchschrank zu müssen.
- Die billigste und auch frickeligste Möglichkeit sind Einport-Injektoren, die man einfach zwischen den Switch und die PD schaltet. Das ist allerdings Flickwerk, weil man ja nur sehr selten nur eine PD zu versorgen hat, die Einport-Injektoren üblicherweise nicht managebar sind und außerdem üblicherweise mit Steckernetzteilen versorgt werden.

Im Standard spezifiziert ist ein Verfahren, mit dem das PSE prüft, ob an einem Port eine PD hängt, und die Spannungsversorgung nur dann aktiviert, wenn eine PD sicher erkannt wurde. Somit soll ein nach 802.3af mit PoE versorgter Port voll abwärtskompatibel zu “normalen” Netzwerkgeräten sein und sicherstellen, dass diese Geräte keinesfalls beim Einstecken fritiert werden.

Zusätzlich zu dem seit 2003 verabschiedeten Standard gibt es noch eine Handvoll herstellerproprietärer Verfahren zur Stromversorgung von Netzwerkgeräten über die Netzwerkverkabelung, die mehr oder weniger kompatibel mit dem Standard sind. Mit solchen Dingen muss man extrem vorsichtig sein, dann mal weichen die Spannungen ab, mal ist die PD-Erkennung anders oder gar nicht implementiert und mal ist nur eine der Versorgungsmethoden in der PD implementiert. Für die herstellerabhängigen Verfahren ist man in der Regel dazu gezwungen, die zu den PDs passenden proprietären PoE-Switches des richtigen Herstellers oder dessen Midspan-Devices zu verwenden, wobei es Midspan-Devices üblicherweise auch nur in der Einzelportausführung gibt.

In der Praxis hat man mit PoE heutzutage in etwa so viel Ärger wie mit Autonegotiation vor zehn Jahren. Damals war es so, dass es durchaus Kombinationen gab, die klaglos funktioniert haben, man aber schon innerhalb der Produktpalette eines Herstellers regelmäßig Kombinationen aus Netzwerkinterface und Switch antraf, die sich partout nicht stabil auf einen Übertragungsmodus einigen konnten. Damals hat man dann halt - so managebar - Switchport und Netzwerkinterface des Gerätes manuell auf einen Modus eingestellt und hatte bis zum nächsten Hardwaretausch oder bis zum nächsten Umpatchvorgang keinen Ärger mehr. Leider gibt es bei PoE-Inkompatibilitäten keinen so einfachen Ausweg.

Am reibungslosesten funktioniert natürlich das Flickwerk, nämlich Einport-Midspan-Injektoren, die man am besten beim gleichen Zulieferer beschafft wie die PDs, damit man jemanden auf den Pott setzen kann, wenn es nicht funktioniert. Dafür zahlt man dann halt den Preis der verhältnismäßig schlechten Managebarkeit und des Chaosses aus Mehrfachsteckdosen, Steckernetzteilen, Powerinjektoren und Patchkabeln im Patchrack, aber wenigstens funktioniert es dann.

Hier eine kurze Auswahl des Ärgers, den alleine ich in zwei PoE-Projekten - vorbereitet oder unvorbereitet - gehabt habe:

PoE-Switche, deren eingebautes Netzteil nur die Hälfte der Ports versorgen kann und die ein externes Extranetzteil brauchen, um an allen ihren Ports die maximale Leistung bereitzustellen.
PDs, die zwar in ihren Datenblättern behaupten, 802.3af kompatibel zu sein, aber nur “Power over Spare Line” unterstützen.
Mehrport-PSEs, die bei Belastung eines Ports oberhalb der Grenze nicht nur die Versorgung des betroffenen Ports abschalten, sondern gleich die Notbremse für die ganze Portbank (nicht selten vier oder acht Ports) ziehen.
PDs, die im Normalbetrieb zwar gut innerhalb der maximalen Leistungsaufnahme (350 mA sind im Dauerbetrieb erlaubt) liegen, beim Einschalten jedoch deutlich mehr als die in der Anfangsphase erlaubten 400mA ziehen und somit in Zusammenarbeit mit einer hinreichend ungeeigneten PSE nicht nur den eigenen Saft, sondern auch den der Portnachbarn gefährden (und nach einem Stromausfall den Wiederanlauf der gesamten Installation verhindern können).
Mehrport-PSEs, die nur die aktuelle Leistungsaufnahme protokollieren, ohne sich zusätzlich einen Maximalwert zu merken.
Hersteller von Mehrport-PSEs, deren Support sich bei einer Anfrage das Datenblatt der PD ziehen, auf deren maximale Leistungsaufnahme gucken und bei “mehr als 15.4W” lapidar sagen “Ihr Gerät nimmt zu viel Strom”, ohne zu berücksichtigen, das das konkrete Gerät sowohl PoE als auch klassische Stromversorgung haben kann, aufrüstbar ist und beim besten Willen bei zwei von acht bestückten Slots sicher nicht in der Größenordnung der maximalen Aufnahme liegt.
Mehrport-PSEs, die zwar die aktuelle Leistungsaufnahme einer PD im Management-Interface anzeigen, deren Hersteller aber die Messwerte des eigenen Produkts nicht glauben mag und sich trotzdem darauf beruft, dass das mit “5.4 Watt” im Managementinterface auftauchende Gerät im gleichen Moment mehr als 15.4 Watt zieht.

Einportinjektoren sind am Markt von fast allen Herstellern verfügbar; wenn es an Mehrport-Injektoren geht wird das Angebot schon deutlich dünner. Es gibt Geräte mit 8, 12, 16, 18 und 24 Ports, aber jedes von einem anderen Hersteller, so dass man sich aussuchen kann, ob man entweder herstellertreu bleiben möchte oder ob man lieber eine bedarfsgerechte Portanzahl einkauft. Bei PoE-fähigen Switches sieht es dann wieder besser aus: Die gibt es in verschiedenen Größen von fast allen Herstellern, nur werden die Dinger relativ schnell ziemlich teuer, wenn man auch noch Wünsche bezüglich Managebarkeit hat. Am realistischsten ist wohl der hp ProCurve 2600-8-PWR, der für einen Straßenpreis von unter 500 Euro einen Gigabit-Uplinkport und acht PoE-fähige FE-Ports mitbringt. Will man mehr Ports haben, muss man tief in die Tasche greifen: In der 48-Port-FE-Klasse bekommt man den hp ProCurve 2650 - ohne PoE - auf der Straße für 350 Euro, während die PoE-Version 2650-PWR (die ohne externes Netzteil nur die Hälfte der Ports voll versorgen kann) mit knapp über 2K mehr als das fünffache kostet. Will man - beispielsweise aufgrund interner Strategieentscheidungen - GE (was es ohne PoE in Form des ProCurve 2848 für knapp 2.5K gibt), hat der Preis für einen vergleichbaren PoE-Switch fünf Stellen und das Gerät mehr als eine HE. So macht das keinen Spaß, und bei anderen Herstellern (z.B. Cisco oder Foundry) sieht es nicht anders aus.

Wir fassen zusammen: Power over Ethernet ist nice to have, wenn sich alle an den - bemerkenswert klar formulierten, und trotzdem an jeder Straßenecke missachteten - Standard halten würden. Tun sie aber nicht, und die allermeisten Produkte könnten auch noch etwas Reife vertragen. Im Augenblick muss man bei jeder Kombination von PoE-Geräten damit rechnen, dass es entweder überhaupt nicht funktioniert oder nur dann, wenn die Mondphase gerade stimmt. Möchte man das Featureset an dem orientieren, was man für normale Netzkomponenten erwartet, muss man für “integriertes” PoE so ganz richtig tief in die Tasche greifen. Nein, diese Technologie muss noch etwas reifen, bevor man sie ohne Schmerzen einsetzen kann. Schade drum.

Next Generation Ethernet Teil 2

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 10 Jul 2005 12:31:25 +0200

Am 2005-07-05 trifft sich der K-Stammtisch (Links hier oder hier, wirklich aktuell sind beide Seiten nicht) zum zweiten Teil des Vortrags von Rolf Sperber über Next Generation Ethernet.

Der ehemalige ATM-Stammtisch hat wieder einen Namen: Das K in K-Stammtisch steht dabei sowohl für Kommunikation als auch für Karlsruhe.

Rolf Sperber, Alcatel, hält heute den zweiten Teil seines Vortrags Next Generation Ethernet.

Das Hauptthema des Vortrags ist OAM (Operation Administration Maintenance) in Ethernet-basierten Weitverkehrsnetzen. Der Vortrag ist nicht so technisch wie der letzte; jedenfalls kann ich diesmal weitgehend problemlos zumindest den Grundideen folgen.

Die wichtigste Aussage war die Trennung zwischen Customer, Provider und Operator, mit der mindestens drei Ebenen der Überwachung im Netz einkehren. In der Praxis hat man eher noch mehr davon, und damit auch mehr als eine Maintenance Association, die immer zwischen Edge und Edge einer Kommunikationsbeziehung besteht.

Ethernet hat bekanntermaßen keinen Managementkanal, so dass man alles in-band transportieren muss. Insbesondere ist bei mehrschichtigen Konstruktionen ein Heartbeat notwendig. Auch bietet klassisches Ethernet keine Handhabe für Performance Management, ohne dass man auf MPLS oder andere Hilfsmittel zurückgreifen muss.

Die Maintenance einer solchen Verbindung wird dadurch erschwert, dass Hops versteckt werden. Ein als “ausgefallen” gezeigter Link besteht in Wirklichkeit aus vielen physikalischen Links. Es muss also auf jeder Ebene OAM stattfinden. Störungen werden auf unteren Ebenen dort bemerkt, wo sie bestehen; auf hohen Ebenen kann man nur die Störung auf einen Bereich eingrenzen und muss sich dann zur Lösung auf den Betreiber der niedrigen Ebene verlassen.

Bei der Initialisierung des Netzes müssen alle Beteiligten die Netztopologie lernen, denn bei einem verbindungslosen Netz wie Ethernet muss man die Gegenseite adressieren können - und die auf Ethernet gängigen Verfahren zum Lernen der MAC-Adresse der Gegenseite funktionieren nur, wenn das Netz in Ordnung ist. Im Störungsfall ist es zu spät.

Der Vortrag ist unter anderem deswegen nicht so konkret, weil Herr Sperber viel über Theorie spricht, für die es noch keine Standards und Implementierungen gibt. Drafts gibt es in manchen Bereichen, aber das ist auch alles.

Die abschließende Diskussion dreht sich stark darum, dass die heute vorgestellten Techniken Probleme lösen, die man mit anderen, bereits existierenden Techniken gar nicht erst hätte. Die Anforderungen für solche Techniken kommt daher, dass man in eine ursprünglich verbindungslose Technik jetzt Verbindungen hineindesigned.

Drei Zitate aus der Diskussion:

“Aus einem alten Lastwagen kann man nur schwer einen Ferrari machen”
“Taugt für Babynetze, aber nicht als allgemein verwendbares Konzept”
“Ethernet ist für Strippen im Haus, maximal auf dem Campus. Kann man damit überhaupt die Welt erobern?”

Der nächste Termin für den K-Stammtisch ist am 2005-09-20

Next Generation Ethernet

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 25 May 2005 00:45:46 +0200

Heute war ich zum ersten Mal seit langer Zeit wieder mal in Karlsruhe aus dem IT-Stammtisch, und durfte einem Vortrag von Rolf Sperber zum Thema “Next Generation Ethernet” lauschen.

Der IT-Stammtisch ist aus dem Karlsruher ATM-Stammtisch hervorgegangen ist und wird seit vielen Jahren von Hans Lackner vorbildlich betreut und organisiert. Von den anderen Netzwerkerveranstaltungen in Karlsruhe unterscheidet sich der IT-Stammtisch dadurch, dass verhältnismäßig wenige Geeks im Publikum sind und sich der Teilnehmerkreis bunt gemischt aus Entwicklung, Marketing und Vetrieb großer und kleiner Firmen zusammensetzt. Graue Haare sind hier deutlich üblicher als zum Beispiel bei SAGE-, Entropia-, CCCS- oder Exlinkertreffen.

Das Publikum ist hochkarätig und die Vorträge haben legendären Ruf dafür, dass sie den Blick über den Tellerrand schärfen, aus den Normierungsgremien berichten und in vielen Punkten das darstellen, was “morgen” unser Alltag sein wird.

Meine Befürchtungen, ich würde “Freunde” aus meiner Vergangenheit wiedertreffen, blieben unbegründet: Mein “alter” Chef hatte sich gar nicht erst angemeldet, und sein Nachfolger stand zwar auf der Teilnehmerliste, erschien dann aber nicht. Dafür waren aber alte Bekannte aus Unizeiten da, und ich fand es schade, mich schon um kurz vor elf rechtzeitig für die letzte Regionalbahn mit Straßenbahnanschluss verabschieden zu müssen.

Heute sprach Rolf Sperber von Alcatel über das Thema “Next Generation Ethernet”. Der Vortrag wurde von vornherein für zwei Veranstaltungen konzipiert, und so haben wir heute nur die erste Hälfte gehört, die mit über 50 Folien ziemlich genau die von mir vorab geschätzten 115 Minuten gedauert hat.

Das waren 115 Minuten gepackte Information und gepackte Technik, gepaart mit den Netzwerkstandard-üblichen Akronymen wie PE, AAL, OAM, MPLS und Konsorten. Wer da eine Minute lang nicht aufpasst, verliert den Anschluss und wird auch nicht wieder aufgesammelt. Mir rauchte der Kopf.

Heute beschäftigte sich Herr Sperber mit dem, was wir heute haben und können und können wollen, und wird auf der nächsten Veranstaltung darüber reden, wie man es eigentlich machen sollte.

Wie wir sicher alle schon gemerkt haben, geht die Tendenz auch in den Weitverkehrsnetzen klar zum Ethernet. Wer sich während des Dotcom-Booms eigenes Glas vergraben hat, kann es sich heute leisten, einzelne Fasern zu verkaufen oder zu verleasen, und die neuen Nutzer der Fasern können dank Wave Division Multiplexing für relativ kleines Geld (wir reden hier nur noch von sechsstelligen Beträgen) geradezu obszön hohe Bandbreiten in der Größenordnung mehrerer hundert Gigabit in die Fasern quetschen - und das ganze mit Run-of-the-Mill-Ethernet-Interfacen, wohlgemerkt.

Das führt natürlich dazu, dass man derzeit tendenziell versucht, alles (und das ist bei weitem nicht nur IP) über Ethernet zu machen. So ist es bereits heute gängig, auf einem Ethernet-Link MPLS zu fahren - und dann innerhalb dieses MPLS wieder Ethernet zu transportieren. Das Buzzword an dieser Stelle ist “Pseudowire”, was meiner Meinung nach sehr schön deutlich macht, worum es eigentlich geht: Virtualisierung, und das auf Verbindungsebene, aber bitte flexibler und einfacher als mit der klassischen Leased Line, die ja auch schon seit langem nur noch auf kürzesten Strecken aus einem durchgehenden Stück Kupfer oder Glas besteht.

Die so eingeführte Virtualisierung durch die zwischendrin eingezogene MPLS-Schicht erlaubt es, auf den verschiedenen Ethernets, die man da - doppelt eingepackt - transportiert, ganz andere Service Levels anzubieten, als man es könnte, wenn man auf dem “unteren” Ethernet einfach VLANs als Service verkaufen würde. Und natürlich kann man auf der MPLS-Schicht auch andere Layer-2-Dienste wie zum Beispiel SDH (und darin dann wieder Telefonie, Videoconferencing und andere anspruchsvolle Bandbreitensäue) transportieren.

Auf diese Weise mutiert Ethernet derzeit gerade zur eierlegenden Wollmilchsau, die die unteren Layer der heutigen Weitverkehrsnetze zu revolutionieren droht.

Die Herausforderung dabei ist, dass man heute nicht mehr davon ausgehen kann, dass eine Datenverbindung komplett im “eigenen” Netz bleibt, und man nicht nur die Grenzen unterschiedlicher Plattformen, sondern auch die Grenzen unterschiedlicher Carrier und ihrer Managementsysteme, und vor allen Dingen Herstellergrenzen überschreiten muss. Somit besteht dringender Bedarf an Konfigurations-, Provisionierungs-, Debugging- und Überwachungsverfahren, die nicht an der ersten erreichten Vendorgrenze anhalten müssen. Da hat die Technik derzeit noch einiges an Nachholbedarf, denn heute ist noch Stand der Technik, dass beim Übergang von einer MPLS-Wolke in die nächste der ganze Datenverkehr aus dem MPLS aus-, in Ethernet-VLANs eingepackt wird, über einen VLAN-Trunk zum nächsten MPLS-PE geschoben und dort prompt wieder verMPLSsed wird. Ein Albtraum für den, der das planen, dimensionieren oder gar konfigurieren muss. Das kann es auf die Dauer nicht sein, und die Hersteller arbeiten fleissig daran, hier direkt miteinander reden zu können.

Weiter in die Technik absteigen werde ich hier nicht. Erstens kann ich das gar nicht in der Detailliertheit hierher transportieren wie es im Vortrag vermittelt wurde, zweitens stehen die Folien bei Hans Lackner im Netz und drittens kann ich mich auch auf andere Arten blamieren als hier per “Stiller Post” fremde Inhalte verfälscht ins Netz zu pusten.

Ich fand den Vortrag hochinteressant, und war mal wieder erstaunt darüber, wie sehr die ausschließliche Arbeit mit IP dazu geeignet ist, einem eine erschreckende Betriebsblindheit zu vermitteln. Kinder, für uns mag es zwar aussehen, als sei “alles bloß IP”, aber unterhalb IP existieren noch weitere Schichten, die alle ihre ganz eigenen Eigenheiten und Anforderungen haben. Und Ethernet schickt sich an, trotz seiner Unzulänglichkeiten (oder wegen seiner Einfachheit?) das universelle, preisgünstige Transportpferd für all dieses zu werden.