Zugschlusbeobachtungen (Entries tagged as netzwerk)

Elektrik, Leitungen, Kabelschächte

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 11 May 2012 13:52:00 +0200

Robert fragt in einem Kommentar zu Bauen, aber wie:

Wie sieht es denn in einem Fertighaus mit der Möglichkeit aus, Kabelschächte mit einzuplanen? Bei einem Steinhaus kann man ja vor dem Verputzen großzügig Schlitze einsetzen. Bei den Fertighäusern aus den 70ern, die ich noch genauer kenne, sind Schlitze mangels Wanddicke keine Option.

Das Thema ist mir als Geek wichtig genug, als dass es einen eigenen Artikel wert ist.

In einem modernen Haus sind Elektroleitungen das Nonplusultra. Man möchte eigentlich einen Hausbus, der mit aktuellem Stand der Technik üblicherweise zentral implementiert wird. Also braucht es von jeder Brennstelle und jeder Steckdose eine eigene Leitung in die Unterverteilung. Dann braucht man als Kommunikationsgeek mehrere Netzwerkanschlußdosen pro Raum; dafür kann die klassische Telefonsteckdose entfallen (wird durch eine Netzwerkdose ersetzt). Und im Zeitalter von Festplattenreceivern reicht eine einzige Antennenleitung pro Raum auch nicht. Dann möchte man vielleicht irgendwann eine Sauna unterm Dach (braucht 3x400V) oder eine Fotovoltaikanlage auf dem Dach (braucht dickes Kupfer).

Und: Anschlußdosen sind immer da, wo man sie nicht braucht, selbst wenn man das Haus selbst geplant hat. Schließlich sehen die Möbel im realen Haus immer anders aus als auf dem Grundriß oder im 3D-Planer. Oder man kauft andere Möbel, die an anderer Stelle viel besser passen. Selbst in unserem gemieteten Wohnzimmer haben wir inzwischen den dritten Standplatz fürs Sofa mit entsprechender Auswirkung auf den Bedarf an Strom- und Netzwerksteckdosen.

Aber nun zur eigentlichen Frage. Du musst hier unterscheiden zwischen dem, was direkt zum Bau des Hauses eingeplant ist und dem, was Du nach dem Bau nachrüsten möchtest. Die größere Flexibilität hast Du natürlich da, was Du planst, bevor in der Fertigungshalle die Holzständer mit Irgendwasfaserplatte beplankt werden. Da werden dann in aller Regel Zugdrähte in den Wänden versenkt, und nach dem Aufstellen des Hauses, aber vor dem Schließen der Decken, die Leitungen eingezogen. Dasselbe gilt sinngemäß für dickere Kabelschächte wie z.B. der Zuführung zum Netzwerkschrank.

Dabei hast Du nahezu alle Freiheiten, wobei es hier bei gewissen Bauweisen vorteilhaft ist, sich an gewisse “Regeln” zu halten. So haben beispielsweise die Holztafelmodule eines uns inzwischen ganz gut bekannten Herstellers bereits ab Werk vorgesehene Kabelkanäle, die man nach dem Aufstellen des Hauses einfachmit dem Dosensenker anbohrt und fertig ist der Zugang zum Kabelschacht. In diesem Werbefilm eines mit Holztafeln arbeitenden Fertighausanbieters sieht man das wenigstens ein wenig. Es ist offensichtlich, dass man es hier einfacher hat, wenn man die Steckdosen so plant, dass sie direkt auf einem Kabelkanal sitzen. Sich nicht an das Raster zu halten, erhöht Preis und Aufwand.

Nachträglich ist auch kein Thema. Die tragenden Elemente des Hauses sind die Holzständer (das ist auch bei Holztafelbauweise so), und wenn Du schlitzt, bleibst Du üblicherweise in der Beplankung der Wand. Und wenn Du das Großverkabelungsprojekt vor hast, nimmst Du einfach die Irgendwasfaserplatten weg und legst die Kabel oder Rohre in die offene Wand. Beim Durchfahren von Geschoßdecken mit Elektrokabeln hast Du denselben “Spaß” wie beim Steinhaus.

Die Innenwände der meisten Fertighäuser haben eine Dicke in der Größenordnung von 15 cm, während das gemauerte Haus, in dem ich derzeit lebe, bei nicht tragenden Innenwänden nur 8 cm Wanddicke hat. Da bin ich schon mehr als einmal unbeabsichtigt mit dem Bohrhammer auf der anderen Seite wieder herausgekommen. Die Außenwände sind natürlich nochmal dicker; hier findest Du üblicherweise eine “normale”, schon ganz ordentlich gedämmte Wand mit einer nochmal zusätzlich aufgebrachten Isolierschicht unter dem Außenputz.

Nichtdestrototz wird man bei größerem Schachtbedarf vermutlich eher mehrere “flache” Kabelkanäle nebeneinander in die Wand einbauen als einen dicken, um sich die Isolationseigenschaften der Wand nicht zu versauen, und dies bevorzugt in Innenwänden tun. Ein Kabelschacht besteht eben größtenteils aus Luft oder aus (gut leitendem) Kupfer, so dass jeder Schacht die Isolation der Wand reduziert.

Zusammenfassung: Wer rechtzeitig und sauber plant, wo Leitungen in sollen, und im Zweifel lieber mehr als weniger in die Wand steckt, kommt auch mit einem Fertighaus klar. Der Spaß beim Nachrüsten von Leitungen ist in ähnlicher Größenordnung wie beim Steinhaus, nur anders.

Noch Fragen?

Imperator des Netzes

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 01 Feb 2009 17:03:00 +0100

Bei $KUNDE standen größere Patcharbeiten an, und ich hatte gerade vierzig Patchkabel der handlichen Länge 0.5 Meter ausgepackt. Wer auf die Idee gekommen ist, so ein Massenprodukt einzeln zu verpacken und die doch “langen” Kabel jeweils mit zweimal Blumendraht zusammenzubinden, weiß ich nicht. Jedenfalls waren die Kabel auch nach dem Auspacken und Austüdeln noch verhältnismäßig eigenwillig mit kleinem Radius gekurvt, so dass sie analog des Lorbeerkranzes prima auf dem Zugschlus-Schädel gehalten haben.

ssh-Zugriff auf ProCurve-Switches automatisieren

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 24 Sep 2008 18:00:00 +0200

In HP ProCurve und ssh habe ich dokumentiert, wie man einem ProCurve-Switch beibringen kann, per ssh zum Management erreichbar zu sein. Leider wird “ssh manger@switch <command>” nicht unterstützt, so dass man Expect braucht, um den Switch zu bedienen.

Nun sind TCL und ich nicht gerade die allerbesten Freunde, und ich erinnere mich mit Schaudern daran, wie ich vor Jahren den Status eines Infortrend-RAIDs mit Expect aus der seriellen Schnittstelle herausgekitzelt habe, um über den Nagios Alarm zu schlagen, wenn eine Platte ausfällt. Also machen wir’s diesmal in Perl.

Noch schwerer wird’s, wenn man die Ausgabe des Switches weiterverarbeiten möchte: Denn das, was aus dem Expect herausfällt, ist voller Steuerzeichen. Hier hilft Term::VT102, ein Perl-Modul, das im Speicher ein VT102-Terminal simuliert, dessen Bildschirm man nach Abschluß der geplanten Aktion auslesen kann. Das habe ich mit einem Scroll-Hook gelöst, der die Daten, die aus dem virtuellen Terminal herausscrollen, in ein Array schreibt. Zum Schluß werden dann einfach genug CRs in das Terminal gekippt, dass auch die letzte Bildschirmseite in unserem Array gelandet ist.

Um die Eigenheiten des Switches zu Umschiffen und sicherzustellen, dass die Daten trotzdem lesbar sind, muss man dem VT102 noch Teile der Cursorbewegung abgewöhnen: Der Switch positioniert den Cursor oft hart, und das terminal kommt dabei durcheinander, wenn die im Switch eingestellte Terminalgröße nicht richtig ist.

Hier ein bisschen Perl, um das gewünschte Verhalten zu simulieren:

#!/usr/bin/perl -wT

package My::Expect;
use Expect;
use Carp;
our @ISA = qw(Expect);

sub expectordie {
    my $self=shift;
    my $timeout=shift;
    if( !defined($self->expect( $timeout, @_ )) ) {
        croak “expectordie failed”;
    }
}

sub send {
    my $self=shift;
    my $send=shift;
    my $debug = $self ? ${*$self}{exp_Debug} : $Expect::Debug;
    my $internal = $self ? ${*$self}{exp_Exp_Internal} : $Expect::Exp_Internal;

    print STDERR “send $send” if ($debug or $internal);
    $self->SUPER::send($send);
}

1;

package main;

use strict;
use Term::VT102;

$ENV{“PATH”}=“/sbin:/bin:/usr/sbin:/usr/bin”;
$ENV{“CDPATH”}=“”;

my @history;

sub my_code_CUP {
    my $self = shift;
    $self->{’x’}=1;
}

sub scroll_down {
    my ($vtobject, $type, $toprow, $numrows, $private) = @_;

    if ($type eq ‘SCROLL_DOWN’) {
        for( my $i=0; $i<$numrows; $i++ ) {
            push( @history, $vtobject->row_plaintext($toprow+$i) );
        }
    }
}

sub filteroutput {
    my $ignorelines=shift(@_);
    my $input=join(“”,@_);
    my $output;
    my $cols=1000;
    my $rows=25;

    my $term = Term::VT102->new (’cols’=>$cols, ‘rows’=>$rows);
    $term->{’_funcs’}->{’CUP’}=\&my_code_CUP;
    $term->callback_set (’SCROLL_DOWN’, \&scroll_down);

    $term->process($input);

    # scroll out the rest
    for( my $i=0; $i<$rows; $i++) { $term->process(“\n”); }

    # ignore given number of lines
    for( my $i=0; $i<$ignorelines; $i++) { shift @history; }

    foreach( @history ) {
        s/\s*$//;
        $output.=“$_\n”;
    }
    return $output;
}

my $userhost=shift @ARGV;
if( $userhost =~ /([a-zA-Z0-9\.@]*)/ ) {
    $userhost = $1;
} else {
    die “Bad chars in command line\n”;
}
my $command=join(“ ”,@ARGV);

my ($user, $host) = split(/@/, $userhost);

my $output=“”;
my $timeout = 4;
my $exp = My::Expect->spawn(“ssh $user@$host”)
  or die “Cannot spawn ssh: $!\n”;
$exp->debug(0);
$exp->raw_pty(1);
$exp->log_stdout(0);
$exp->expectordie($timeout, ‘Press any key to continue’);
$exp->send(“\n”);
$exp->expectordie($timeout, ‘-re’, ‘[a-z0-9]+# ‘);
my $prompt = $exp->match();
$exp->send(“term length 999\n”);
$exp->expectordie($timeout, “$prompt”);
$exp->send(“$command\n”);
$exp->log_stdout(0);
while( $exp->expect($timeout, (’MORE --, next page: Space, next line: Enter, quit: Control-C’,
“$prompt”) ) == 1 ) {
    $exp->send(“ ”);
    $output.=$exp->before();
}
$output.=$exp->before();
$exp->log_stdout(0);
$exp->send(“logout\n”);
$exp->expectordie($timeout, ‘Do you want to log out [y/n]? ‘);
$exp->send(“y\n”);
if( $exp->expect($timeout, ‘Do you want to save current configuration [y/n]? ‘, ‘closed by remote
host.’)==1 ) {
    $exp->send(“y\n”);
    $exp->expectordie($timeout, ‘closed by remote host.’);
}
$exp->expectordie($timeout, eof);
$exp->soft_close();

print filteroutput(1, “$output”);

print “\n”;

MSTP mit HP ProCurve

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 24 Sep 2008 12:43:36 +0200

Das Spanning Tree Protocol (STP) ist ein Protokoll, das den Betrieb von lokalen Netzen (z.B. auf Ethernet-Basis) mit Redundanzen erleichtern soll. Diesen Job macht es “reasonably well”, ich möchte an dieser Stelle aber nicht unerwähnt lassen, dass es auch schon zu grauen Haaren beim einen oder anderen Netzwerker geführt hat. Es gibt es in vielen verschiedenen Darreichungsformen, und in diesem Artikel möchte ich versuchen, die Grundlagen so weit aufzuarbeiten dass ich dann zu meinem aktuellen Projekt, MSTP, auch noch etwas schreiben kann.

Ein gewaltiger Fallstrick beim Betrieb von Ethernet ist, dass das Protokoll keinen Time-To-Live-Mechanisus hat, und ein Frame, das sich aus irgendwelchen Gründen zwischen zwei oder mehr Geräten im Kreis dreht, dies somit bis zum Ausfall des Netzes oder manuellem Eingriff weiter tut, bis in alle Ewigkeit.

Dieses Verhalten gepaart mit dem Wunsch vieler Netzwerkbetreiber nach üblicherweise durch den Bau von Ringen ausgedrückter Redundanz im Netz, der Eigenschaft von IP over Ethernet, dass Switches Broadcastpakete auf allen Ports rausflooden müssen und der Tatsache, dass das für IP essentiell notwendige Address Resolution Protocol (ARP) zwingend mit Broadcasts arbeitet, führt in der Abwesenheit von Sicherungsmechanismen wie STP zu Broadcaststürmen, deren Auftreten sich in aller Regel massiv negativ auf den Netzwerkbetrieb auswirkt.

Das Heilmittel gegen solche Katastrophen heißt wie schon in diesem Artikel erwähnt Spanning Tree. STP erkennt in einer Netzwerkstruktur Zyklen und trennt diese Zyklen durch Abschalten einzelner Ports auf, so dass ein zyklenfreier Graph aus Netzwerklinks entsteht. Wenn nun dieser zyklenfreie Graph durch Störungen in zwei Teile zerfällt, wird das von STP erkannt und die abgeschalteten Ports wieder so eingeschaltet, dass der Graph wieder zusammenhängend ist. Er sieht dann zwar anders aus als zuvor, aber er ist wieder zusammenhängend und die Kommunikation kann wieder funktionieren.

Das heute in einfachen Netzen eingesetzte Spanning Tree Protokoll ist üblicherweise Rapid Spanning Tree, das sich vom klassischen STP - der Name lässt dies schon vermuten - dadurch unterscheidet, dass es nach Topologieänderungen schneller wieder einen stabilen Zustand erreicht.

STP und RSTP arbeiten allerdings auf Portbasis. Das wird dann interessant, wenn VLANs im Einsatz sind, denn diese beiden einfachen Protokolle schalten Ports ab, ohne sich für die auf den Ports konfigurierten VLANs zu interessieren. Hier ein Beispiel:

 ---------
 | sw11  |---------------------|
 ---------  1                  |
     |  2          Data        |
     |             Center      |
     | 401,403                 | 401,402,403
     |                         |
     |                         |
     |  2                      | 1
 ---------   401,402,403   ---------
 | sw12  |-----------------| sw 13 |
 --------- 13           13 ---------

Wir haben hier drei Switche, in einem Ring aufgebaut, mit drei VLANs: 401, 402 und 403. Nun ist VLAN 402 auf dem Link zwischen Switch 11 und Switch 12 nicht konfiguriert. Entscheidet sich RSTP nun dazu, zur Auflösung des Rings den Link zwischen Switch 12 und Switch 13 abzuschalten, ist Switch12 in VLAN 402 nicht mehr erreichbar - ein Zustand, den wir üblicherweise nicht haben wollen.

Das hat mich seinerzeit bei meinem ersten komplexeren Netzprojekt mit HP ProCurve-Switchen überrascht, weil sich die Cisco-Switche, mit denen ich davon gearbeitet habe, anders verhalten: Cisco benutzt sein proprietäres Protokoll PVST (Per-VLAN Spanning Tree), was für jedes VLAN einen eigenen Spanning Tree verwendet. Im oben gezeichneten Beispiel würde PVST also für die VLANS 401 und 403 je einen Ring sehen und diesen Ring auftrennen. VLAN 402 würde PVST jedoch in Ruhe lassen, denn VLAN 402 hat keine Zyklen. Erster Lerninhalt: Das was Cisco macht, ist proprietär und funktioniert nur mit Cisco. Zweiter Lerninhalt: Wenn man RSTP mit HP-Gear macht, muss man auf allen Interswitchlinks alle VLANs transportieren, sonst passieren grausame Dinge. Auf einem so einfachen Netz mit drei Switches ist das natürlich kein Problem. Wohl aber, wenn man z.B. VLANs benutzt, um nicht alle Daten an allen Stellen im Netz zugänglich zu haben.

Wenn man das Ergebnis von PVST mit HP-Gear nachbauen will, verwendet man MSTP, das Multiple Spanning Tree Protocol. Beim MSTP definiert man unterschiedliche Spanning-Tree-Instanzen und ordnet ein oder mehrere VLANs den Instanzen zu. Leider ist das so komplex, dass man in einem so einfachen Setup mit nur drei Switchen wie oben gezeichnet mit MSTP nicht weit kommt; wenn man das wirklich am Fliegen sehen möchte, sollte man mehrere Ringe bauen können. Netterweise hat $KUNDE hierfür sieben Switche bereitgestellt, die mir für einige Wochen zum Testen zur Verfügung standen. Meine Testumgebung würde auch mit zwei Switchen weniger funktionieren, aber das Werfen von mehr Hardware hat noch ein bisschen besseren Einblick gegeben.

Und so sah das ganze Spiel aus:

 Access
      | 9
 ---------
 | sw11  |---------------------|
 ---------  1                  |
     |  2          Data        |
     |             Center      |
     | 401-403t                | 401-403t
     | 1u                      | 1u
     |                         |
     |  2                      | 1
 ---------   401-403t      ---------
 | sw12  |-----------------| sw 13 |
 --------- 13  1u       13 ---------
     | 24                   25 |
     |                         |
     | 401t, 403t              | 401t, 403t
     | 1u                      | 1u
     |                         |
     | 24                   25 |
 ---------                 ---------
 | sw24  |                 | sw 25 |
 ---------                 ---------
     | 26                   27 |
     |                         |
     | 401t, 403t              | 401t, 403t
     | 1u           offices    | 1u
     |                         |
     | 26                   27 |
 ---------    401t,403t    ---------
 | sw26  |-----------------| sw 27 |
 --------- 28    1u     28 ---------

Die Switches 11, 12 und 13 stehen in einem simulierten Rechenzentrum und bilden für sich einen Ring. Die Switches mit den Zwanziger-Nummern sind über ein gedachtes Gebäude verteilt und binden die Arbeitsplatzrechner an. Das VLAN 402 transportiert rechenzentrums-interne Daten; seine Inhalte sollten in den Büroräumen nicht abgreifbar sein. Das VLAN 1 dient dem Switchmanagement und wird auf allen Links “untagged” transportiert.

Daraus entstand dann die folgende Switch-Konfiguration (in der für ProCurve 2848 relevanten Notation; die neueren 2810-48G weichen hier in Details ab) für alle Switche:

vlan 1
   name “DEFAULT_VLAN”
   untagged 1,2,9,13,24,25,26,27,28
   ip address 10.3.1.<switch> 255.255.255.0
   exit
vlan 401
   name “VLAN401”
   ip address 10.3.11.<switch> 255.255.255.0
   tagged 1,2,9,13,24,25,26,27,28
   exit
vlan 403
   name “VLAN403”
   ip address 10.3.13.<switch> 255.255.255.0
   tagged 1,2,9,13,24,25,26,27,28
   exit
spanning-tree
spanning-tree protocol-version MSTP
spanning-tree config-revision 2
spanning-tree instance 1 vlan 401 403

Die 10er-Switche haben noch zusätzlich:

vlan 402
   name “VLAN402”
   ip address 10.3.12.<switch> 255.255.255.0
   tagged 1,2,9,13
   exit
spanning-tree instance 2 vlan 402

Diese Materialschlacht funktioniert so wie beabsichtigt: Obwohl das VLAN 402 nicht mehr auf allen Switchen konfiguriert ist, sind alle Switche im Normalbetrieb in allen VLANs erreichbar. Auch das Ziehen einzelner Patchkabel stört den Betrieb nicht; der simulierte Ausfall eines ganzen Switches (Stromstecker raus) macht nur den einzelnen Switch unerreichbar. Die durch die Rekonfiguration des Spanning Tree zweifellos entstehende Unterbrechung ist kurz genug, dass ein im Sekundentakt abgesetztes ping die Störung nicht bemerkt.

Anders ist es allerdings, wenn man die so erzeugte Störung behebt: Dabei verschluckt sich der Spanning Tree für etwa fünfzehn Sekunden, bevor wieder alle Switche erreichbar sind. Während dieses Verschluckens kommt es regelmäßig vor, dass auch Switche in der näheren Umgebung der Störung kurz nicht mehr erreichbar sind. Das ist wenig schön, aber in diesem Zeitrahmen IMO akzeptabel.

So lange mir die Testhardware noch zur Verfügung steht, werde ich eine Prozedur entwickeln, ein Netz im laufenden Betrieb auf MSTP umzustellen.

Sehr hilfreich bei dieser Operation war übrigens mein serieller Konsolen-Server für Arme, denn es debugged sich deutlich leichter, wenn man die Konsolenausgabe aller Switche gleichzeitig im Blickfeld hat. Syslog bringt’s hier nicht, denn wenn der Switch grad nicht erreichbar ist, wird er auch keine syslog-Einträge los. Das Gegenstück zu Ciscos “term mon”heißt bei HP übrigens

debug destination session
debug all
no debug lldp

Konfigurationsfehler verhindert man dadurch, dass man die Konfiguration nicht manuell vornimmt, sondern für alle Switche mit einem kleinen Shellscript generiert und per tftp auf die Switche schiebt. Das hat den Vorteil, dass Fehler wenigstens systematisch auf allen Switches gemacht werden (was mich drei Tage für die Fehlersuche gekostet hat, **grml**).

hp Supportchat völlig unbrauchbar

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 02 Jun 2008 12:24:31 +0200

Ich möchte ein Notebook hp nc 8000 per Wake-on-LAN aufwecken, um sicherzustellen, dass es möglichst immer läuft. Leider habe ich im BIOS keine Einstellung für Wake-on-LAN gefunden, und ein per etherwake oder wakeonlan gesendetes magisches Paket wird ignoriert. Also versuche ich mal den hp-Supportchat, vielleicht bin ich ja nur zu doof zum suchen.

Ich bekomme innerhalb von wenigen Minuten Pavel K als Supportspezialisten zugewiesen, der zunächst nochmal den Typ und die Seriennummer des Notebooks abfragt. Er antwortet dann, dass Wake on LAN beim nc8000 nicht unterstützt wird. Lüge Nummer eins, denn schon in der Produktbeschreibung steht natürlich dass Wake on LAN unterstützt wird, und außerdem funktioniert das bei unseren Notebooks in der Firma ja auch prima.

Als nächstes versucht Pavel, mich mit einem BIOS-Update abzuspeisen und pastet mir den LInk auf das Bios F.0C vom 05. März 2004. Wir erinnern uns, in diese Falle bin ich am Wochenende auch schon getappt. Ich weise Pavel darauf hin und bitte ihn, mal das SP-Paket auszupacken und ins README zu gucken. Das aktuelle Bios F.18 ist bereits installiert.

Es folgt das Unvermeidliche: Er sagt, ich soll im Gerätemanager mal das und das nachgucken. Ich antworte ihm korrekt und höflich, dass auf dem System Linux installiert ist, und er nutzt diese Gelegenheit, um sich final aus der Affäre zu ziehen: Linux sei “als Software” auf dem nc8000 nicht unterstützt. Lüge Nummer zwei, denn hp ist im Bereich Linux-Unterstützung sehr rührig.

Meinen Hinweis auf die “Linux auf dem nc8000”-Webseite innerhalb des hp-Webangebots kommentiert er damit, dass das nc8000 zwar für Linux zertifiziert, aber nicht supported sei. Ich gebe auf.

Fazit: Die Unterstützung von Linux durch hp ist nach wie vor hauptsächlich ein Lippenbekenntnis, weil die Leute an der vorderen Supportfront nicht ausgebildet sind oder anders lautende Dienstanweisungen haben. Linux ist immer noch die finale Ausrede, sich mit “nicht supported” davonzustehlen.

Und wie Wake-on-LAN funktioniert, weiss ich immer noch nicht.

2006-10-12 - Admintipp des Tages

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 12 Oct 2006 13:43:04 +0200

Der VLAN-Beauftragte rät: Ja, hp ProCurve Switches 2650 haben für die Dual-Personality-Ports zwei Registersätze. Und nein, es ist deswegen nicht zielführend, zuerst den Port zu konfigurieren, dann den GBIC reinzustecken und das Ding so dann zum Kunden zu shippen. Weil, mit einem Port, der untagged im Default-VLAN ist, kann der Kunde nicht so viel anfangen.

Steckerbelegung in strukturierter Verkabelung

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 21 Oct 2005 12:04:36 +0200

Ein Kollege wollte neulich einen Gigabit-Link über den folgenden Stecker aufbauen.

Ich hab ihn erstmal rund gemacht, weil “bei so einer Sparbelegung kann das nicht funktionieren. Da wird ja nichtmal E oder FE gehen! Welcher <zensiert> hat denn das verbockt?”

Er steckte wortlos das Patchkabel rein und das Licht am Switch ging an. Sogar in der richtigen Farbe.

Whisky Tango Foxtrot?

Nun, die Lösung steckte direkt daneben.

Aber: Was hat einen Artikelmenschen geritten, einer 1-8 durchverbundenen RJ45-Dose ausgerechnet die Artikelnummer 3645 zu geben?