Man bemächtige sich iperf und lasse dann einige Tests laufen:

Server

In meinem Fall Debian mit Kernel 2.6.18-4-686; Intel PWLA8391GT und Intel Pentium III 600MHz:

ALPHA:/tmp# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

Client

In meinem Fall Mac OS X 10.3.9; Gigabit-Ethernet (Chipsatz unbekannt) und PowerPC G5 2x 1.8GHz:

beta:~/Desktop mario$ ./iperf -c 192.168.0.101
------------------------------------------------------------
Client connecting to 192.168.0.101, TCP port 5001
TCP window size: 65.0 KByte (default)
------------------------------------------------------------

Resultate

[  4] local 192.168.0.101 port 5001 connected with 192.168.0.102 port 49664
[  4]  0.0-10.0 sec    431 MBytes    361 Mbits/sec
[  5] local 192.168.0.101 port 5001 connected with 192.168.0.102 port 49665
[  5]  0.0-10.0 sec    349 MBytes    293 Mbits/sec
[  4] local 192.168.0.101 port 5001 connected with 192.168.0.102 port 49666
[  4]  0.0-10.0 sec    410 MBytes    343 Mbits/sec

Wow – schneller als das Licht!

Dass ich heute Freitag morgen etwas müde aus der Wäsche geguckt habe, hängt einerseits mit den 1. Schweizerischen Geschichtstagen zusammen, die derzeit in Bern stattfinden. Andererseits aber auch, weil gestern digitec endlich das heissersehnte Päckchen geliefert hat.

Komponenten

Dessen Inhalt:

• Intel PWLA8391GT Pro 1000GT Gigabit Adapter PCI
• ZyXEL GS-105A, Gigabit Switch, 5x 10/100/1000Mbps

Fallstrick ethX

Im Server werkelte bisher eine dieser „tubelisicheren“ 3Com-Karten, für die Linux wohl seit Ewigkeiten Treiber-Support mitbringt. Deren Dienstpflicht war nun zu Ende und sie wurde zwecks Antritt des Ruhestands ausgebaut. In denselben Slot steckte ich nun die Gigabit-NIC.

Der erste Boot-Vorgang mit der neuen Ethernet-Karte verlief zu Beginn völlig reibungslos – mit dem mit Ctrl-S zu erreichenden Konfigurations-Menu schaltete ich die PXE-Funktion aus und sparte so ca. 10-20 Sekunden, die für die Suche nach einem DHCP-Server draufgingen.

Als jedoch Linux die Kontrolle übernahm, klappte dagegen nicht alles sauber. Zwar wurde das für den Betrieb der Netzwerkkarte nötige Modul e1000 anstandslos geladen – im Laufe des Boot-Prozesses stachen mir aber einige FATAL-Meldungen ins Gesicht, die sich auf eth0 respektive e1000 bezogen („could not set device flags“ oder ähnlich). Was zum Teufel?

Jedenfalls hatte ich keine aktive Netzwerkverbindung zur Verfügung, und ifconfig zeigte kein schönes Bild:

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:323240 errors:0 dropped:0 overruns:0 frame:0
          TX packets:323240 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:226873684 (216.3 MiB)  TX bytes:226873684 (216.3 MiB)

(Ersatz-Ausgabe nach 24h Betrieb). Wo blieb eth0?

Nach einer ca. 30 Minuten dauernden Schrecksekunde, die auch unzählige Google-Suchen beinhaltete, fand ich die Lösung dann eher unerwartet, als ich folgenden Befehl eingab:

ifconfig -a

Dort wurde eth1 erwähnt, eth0 fehlte hingegen. Wieso das so ist, kann ich mir immer noch nicht erklären. Entweder hat Linux die Identifikation der Vorgänger-Karte gespeichert und vergibt neuen Karten eine fortlaufende Nummer, oder irgendwas ist mit dieser NIC anders. Ich weiss es nicht.

Jedenfalls genügte es nun, eth0 in /etc/network/interfaces mit eth1 zu ersetzen. Nach dem nächsten Reboot funktionierte die Karte endlich.

Fallstrick Patchkabel

ALPHA kernel: e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex

Was’n löus? Wieso nur 100 Mbps, wenn ich doch soeben viel Geld für ein Gigabit-Netzwerk ausgegeben hatte?

Meine erste Vermutung erwies sich dieses eine Mal als goldrichtig: Das ca. 2001 mit dem Kauf eines Wireless-Access-Points (Elsa/Lancom L-11) mitgelieferte Patch-Kabel erfüllte die Qualitätsanforderungen an ein Gigabit-Netzwerkkabel nicht (mind. Cat 5e – hier wohl Cat 5). Nachdem ich dieses Kabel entfernt und mit einem neueren Modell ersetzt hatte, hiess es nun endlich:

ALPHA kernel: e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

Durchsatz?

Folgender Test führte ich aus „Gwunder“ durch, um den Durchsatz zu messen:

BETA:/Volumes/INCOMING/KNOPPIX mario$ time cp KNOPPIX_V5.1.1CD-2007-01-04-EN.iso /Volumes/Multimedia/Software/

real    0m39.920s
user    0m0.040s
sys     0m6.730s

40 Sekunden für ein knapp 700MB grosses File? Das ergibt 17.5MB pro Sekunde oder 140Mbit/s. Freude herrscht!

Doch wieso? Die errechnete Zahl ist ja meilenweit von 1000Mbit/s weg … Ja, schon, aber:

1. Das CIFS/SMB-Protokoll ist nicht gerade bekannt dafür zu sein, besonders performant zu laufen (die Datei wurde von einem unter Mac OS X gemounteten Samba-Share auf die lokale Festplatte kopiert)
2. Auch wenn es sich um eine Intel-Netzwerkkarte handelt – im Vergleich zu einer PWLA8490MT muss wohl irgendwo gespart worden sein. Ich betrachte die im Einsatz befindliche Karte als Consumer-Variante.
3. Dasselbe gilt wohl für den Netzwerk-Chipsatz im PowerMac G5
4. Auch der Zyxel-Switch GS-105A ist ein Consumer-Gerät, von dem nicht Spitzenleistungen erwartet werden dürfen
5. Die Festplatten im Quellsystem (ATA100, RAID10) sowie die SATA im Zielsystem sind wohl die Bottlenecks
6. Jumbo-Frames sind keine im Einsatz – Mac OS X erlaubt diese Option nur bei den Xserves

Wie dem auch sei – der Geschwindigkeitsgewinn ist bereits jetzt äusserst spürbar und ich habe absolut keinen Grund für Wehklagen.

Da habe ich mich heute kurzerhand dazu entschlossen, meinen IPCop-Router (Pentium 90 auf einem Asus P5A-B – bald ein Museumsstück!) durch die hier herumgammelnde Fritz!Box Fon 5012 zu ersetzen, doch – schreck lass nach – das Ding bringt natürlich keinen SNMP-Support mit sich. Was nun?

UPnP?

Nun gut, was sich hinter UPnP genau verbirgt, lese ich ein andermal nach. Jedenfalls scheint dieses Protokoll/Feature von Natur aus sehr geschwätzig zu sein, was den Traffic anbelangt. Ein findiger Linux-Hacker hat denn auch schon ein kleines, aber hochstehendes Shell-Scriptlein programmiert, das MRTG (der Vorfahre von rrdtool, auf das cacti exzessiv zurückgreift) „füttert“:

Monitoring Fritz!Box With MRTG

Bastelstunde

Was wäre eine schicke Linux-Anwendung, wenn man nicht auch hier etwas Hand anlegen und Feintuning betreiben müsste (vom Grundkonzept her zu vergleichen mit Alpinisierern und Brabierern)? Damit das Scriptlein auch mit cacti zusammenspielt, habe ich den Shell-Output folgendermassen umgebogen:

...
# output for mrtg
printf "IN:${b1:-UNKNOWN} OUT:${b2:-UNKNOWN}\n"
#printf "%s\n%s\n%d days %.2d:%.2d:%.2d h (online)\nFritz!Box\n" \
#  "IN:${b1:-UNKNOWN}" "OUT:${b2:-UNKNOWN}" "${h% *}" "${h#* }" "${m#* }" "${s#* }"
...

Nachtrag

Der 32bit-Counter generiert im Laufe der Zeit einen Overflow und kehrt sich ins Negative. Das bringt cacti/rrdtool leider gehörig draus, obwohl dieses Verhalten gerade bei Traffic-Messungen zur Tagesordnung gehört.

Folgender Einschub korrigiert den Effekt:

if [ "$b1" -lt "0" ]; then
        c1=$[ (-4294967296 - $b1) * -1 ]
else
        c1=$b1
fi

if [ "$b2" -lt "0" ]; then
        c2=$[ (-4294967296 - $b2) * -1 ]
else
        c2=$b2
fi

Die auszugebenden Variablen müssen danach noch im Abschnitt #output for mrtg angepasst werden:

printf "IN:${c1:-UNKNOWN} OUT:${c2:-UNKNOWN}\n"

Integration in cacti

Damit kann man nun eine neue Datenquelle anlegen und daraus einen Graphen generieren lassen. Ich empfehle, bei der Erstellung des Graphen ‚Interface (bytes/sec)‘ zu wählen.

Man versieht sich darauf hin kaum, und die Graphen sprudeln wieder. Schick, nicht wahr?

Dieser Artikel entspricht einem E-Mail, das ich im August 2006 den Informatikdiensten meines Arbeitgebers übermittelt habe.

Guten Tag

Vor einiger Zeit habe ich eine Anfrage an Sie gestellt, wie es mit den neuen Switches und VLAN möglich ist, mit einem physischen Gerät auf mehreren Subnetzen zu lauschen. Ich benötige diese Funktionalität für meinen arpwatch-Server, der mich über Aktivitäten unserer Netzwerk-Geräte informiert (IP-Wechsel, MAC-Adressen-Wechsel, neue Geräte etc.)

Mit dem Wechsel des Gebäudes in das VLAN 38 funktioniert der Server nun wie gewünscht. Im Anschluss eine kurze Anleitung für Debian Linux:

Voraussetzungen

• Debian Linux mit Kernel 2.6.15-1-686 (es traten Probleme mit Kernel 2.6.8 auf – die Konsole wird mit Fehlermeldungen vollgespammt)
• Modul 8021q resp. 802.1q-Funktionalität in Kernel einkompiliert
• Package vlan (apt-get install vlan); u.a. mit dem Tool vconfig zur manuellen Erstellung von Interfaces
• Netzwerk-Anschluss, auf den mehrere VLAN-IDs gemappt sind ([…]).

/etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.0.2
        netmask 255.255.255.0
        broadcast 192.168.0.255

auto eth0.38
iface eth0.38 inet static
        address 130.92.38.76
        netmask 255.255.255.0
        network 130.92.0.0
        broadcast 130.92.38.255
        gateway 130.92.38.1
        dns-nameservers 130.92.9.51 130.92.9.52
        pre-up /sbin/vconfig add eth0 38

auto eth0.40
iface eth0.40 inet static
        address 130.92.40.6
        netmask 255.255.255.0
        network 130.92.0.0
        broadcast 130.92.40.255
        pre-up /sbin/vconfig add eth0 40

auto eth0.152
iface eth0.152 inet static
        address 130.92.152.6
        netmask 255.255.255.0
        network 130.92.0.0
        broadcast 130.92.152.255
        pre-up /sbin/vconfig add eth0 152

Das Laden dieser Einstellungen wird zwar von Fehlermeldungen begleitet, aber es scheint trotzdem zu klappen (?).

/etc/arpwatch.conf

# /etc/arpwatch.conf: Debian-specific way to watch multiple interfaces.
# Format of this configuration file is:
#
# 
# 
#...
# 
#
# You can set global options for all interfaces by editing
# /etc/default/arpwatch

#eth0   -m root+eth0
#eth1   -m root+eth1

eth0            -N -n 130.92.0.0/16 -m mario.aeby@domain.tld
eth0.38         -N -n 130.92.0.0/16 -m mario.aeby@domain.tld
eth0.40         -N -n 130.92.0.0/16 -m mario.aeby@domain.tld
eth0.152        -N -n 130.92.0.0/16 -m mario.aeby@domain.tld

[…]

Mit freundlichem Gruss
Mario Aeby
—
Mario Aeby
IT-Verantwortlicher & Web-Developer

Departement Klinische Forschung
Murtenstrasse 35
CH-3010 Bern