blog/shl@INTERDOSE

Wir alle sind Systemhelden. Und wie es bei fast allen anderen heldenhaften Tätigkeiten gleich ist, leben wir Systemhelden vom Austausch von Wissen.

Die HELDENBlogs sind genau dafür ideal, doch leider verwehren uns die Helden-Entwickler einen sinnvollen RSS-Feed über die Artikel der Helden-Kollegen.

Bitte, liebe Systemhelden-Entwickler. Bitte baut einen RSS-Feed über die HELDENBlogs ein. Ihr bekommt dann auch Gummibärchen von mir!

Wer genauso denkt wie ich, soll sich doch bitte in den Kommentaren verewigen. Vielleicht hören die Helden-Entwickler auf die Stimmen von vielen Systemhelden.

Niemand will Backups - alle wollen nur Restore.

Zum Beispiel für Home-Directories oder Projekt-Volumes bietet OpenAFS intern wunderbare Möglichkeiten: es unterstützt Backup-Volumes.

vos backup user.testuser erzeugt ein Backup des Volumes direkt auf sich selbst. Was genau bedeutet das? Zum letzten Backup wird ein delta angelegt, so daß z.B. die Datenbestände des letzten Arbeitstags in diesem Backup auf das Restore warten.

Und warum ist das jetzt so toll? Das kann doch bisher jedes einigermaßen anständige Dateisystem. Das Backup-Volume taucht in der Volume-List auf und ist mountbar. fs mkm /afs/.zelle/user/testuser/yesterday user.testuser.backup

Die Automatisierung dieses Prozesses geschieht über das folgende Kommando.
bos create server backuptestuser cron -cmd “/usr/bin/vos backupsys user.testuser -localauth” “03:00“

• server sollte der Volume-Server sein, auf dem das Volume user.testuser als RW-Instanz liegt.
• backuptestuser ist ein willkührlich gewählter Name für den Job.
• user.testuser ist der Name des zu sichernden Volumes.
• 03:00 ist die Uhrzeit. 03:00 ist 3am, 15:00 entspricht 3pm.

Der User kann jetzt direkt im Verzeichnis yesterday den Datenbestand einsehen und lesend nutzen. Backup-Volumes sind natürlich read-only.
fs lsmount yesterday zeigt übrigens an, daß es sich um ein Backup-Volume handelt.

‘yesterday’ is a mount point for volume ‘#user.testuser.backup’

Software-Deployment von Hand ist grausam - da sind wir uns wohl alle einig. Früher™ war es durchaus etwas grausamer - ich erinnere mich grade an das Disketten-Gebirge von Novell Netware oder OS/2 zurück - doch auch heute schubsen wir immernoch Betriebssystem auf Rechner, also eigentlich genau wie früher.

Ein schöner Vorteil der “freien” Betriebssysteme ist an dieser Stelle, daß man sie nahezu alle auch aus dem Netzwerk booten kann - Stichwort PXE - und somit zumindest das Erstellen von Installationsmedien entfällt.

Mit einem PXE-fähigen Rechner ist man in der Lage, anstelle von lokalen Medien (Festplatte, Diskette, CD etc.) über ein Netzwerk (Ethernet) von einem entfernten Rechner zu booten. Dies kann dazu dienen, auf einem Rechner ohne Zufügen von Medien (CDs, DVDs etc.) ein Betriebssystem zu installieren oder auch ein Thinclient-System aufzubauen, in dem die Client-Rechner gar keine Laufwerke benötigen, und dem Nutzer dennoch ein komplett nutzbares Betriebssystem zur Verfügung gestellt wird.

[nach wikipedia]

Wie baut man denn jetzt ein solches PXE-Environment auf? Naja - eigenlich recht einfach. Man benötigt nur den Dienst DHCP, eine Portion TFTP und später etwas NFS - schon fertig. In der Realität ist’s natürlich ein kleines bisselchen mehr Aufwand…

Zuerst suchen wir uns eine Maschine im Netz, auf der das PXE-System laufen soll. In meinem Falle ist das eine Debian Maschine, konzeptionell funktioniert das aber auch wunderbar mit anderen Distributionen oder den BSD-Geschmacksrichtungen. Ich habe mir vor einiger Zeit mal angewöhnt solche Installationen getrennt vom restlichen Betriebssystem zu verwalten, daher wähle ich einen Pfad unterhalb von /opt - das steht natürlich jedem frei.

# mkdir /opt/pxeboot/tftp

Was wir auf jeden Fall brauchen, ist eine aktuelle Version von syslinux - runterladen und in diesem neuen Verzeichnis entpacken.

Den Debian-Installer laden wir als nächstes. Heute gibt es durchaus Sinn sowohl den i386- als auch den AMD64-Zweig anzubieten, daher laden wir beide nacheinander runter und entpacken die Files ebenfalls nach /opt/pxeboot/tftp.


# wget http://ftp.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/netboot.tar.gz
# tar xzf netboot.tar.gz
# rm netboot.tar.gz
# wget http://ftp.debian.org/debian/dists/etch/main/installer-amd64/current/images/netboot/netboot.tar.gz
# tar xzf netboot.tar.gz
# rm netboot.tar.gz


Beide Dateien heißen netboot.tar.gz, also nicht aus Versehen gegenseitig überschreiben. Ein paar Dateien sind in beiden Archiven enthalten - einfach ignorieren, die dürfen ruhig überschrieben werden. Ebenfalls brauchen wir zwei Symlinks nicht mehr - pxelinux.0 und pxelinux.cfg sollten auch gleich gelöscht werden - wir legen sie später neu an.

Aus dem syslinux-Paket stibitzen wir noch die Datei com32/modules/menu.c32 und kopieren sie nach /opt/pxeboot/tftp.

Dem DHCP-Server in unserem Netz muß noch erklärt werden, daß er den Clients auf PXE-Anfragen antwortet. Beim ISC DHCPd3 geht das sehr schmerzfrei, auch bei anderen DHCP-Servern sollte das kein Problem sein. (moemoe beschreibt das mit dnsmasq)


subnet 172.30.4.0 netmask 255.255.252.0 {
 range 172.30.6.1 172.30.6.254;
 range dynamic-bootp 172.30.5.240 172.30.5.255;
 option routers 172.30.7.254;
 filename “pxelinux.0″;
 next-server 172.30.4.1;
}


Die beiden hervorgehobenen Zeilen teilen dem Client mit welche Datei er von welchem Server per TFTP anfordern soll. Installieren wir noch einen TFTP-Server! Wer Debian einsetzt kann sich jetzt glücklich schätzen, denn was gibt es schon schöneres als apt-get?


# apt-get install atftpd


Bei mir wird der atftpd per inetd gestartet, also muß eine entsprechende Zeile in die /etc/inetd.conf

tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /opt/pxeboot/tftp Einfach ganz unten anhängen - sofern da noch nix von tftp steht - und darauf achten, daß es wirklich alles eine Zeile ist.

Jetzt noch das Boot-Menü anpassen.

In /opt/pxeboot/tftp ein neues Verzeichnis namens pxelinux.cfg erstellen und darin eine Datei namens default in den Editor laden.


DEFAULT menu.c32
PROMPT 0
MENU TITLE Automagisches Netzwerk-Booten
TIMEOUT 300
LABEL d
 MENU DEFAULT
 MENU LABEL Boot from ^disk
 localboot 0x80
LABEL di-i386
 MENU LABEL Debian Installer ^i386 - submenu
 KERNEL menu.c32
 APPEND debian-installer/i386/pxelinux.cfg/default
LABEL di-amd64
 MENU LABEL Debian Installer ^amd64 - submenu
 KERNEL menu.c32
 APPEND debian-installer/amd64/pxelinux.cfg/default
LABEL n
 MENU LABEL Try ^next bootdevice
 localboot -1


Aus dem Debian-Installer i386 (/opt/pxeboot/tftp/debian-installer/i386) noch die Datei pxelinux.0 nach /opt/pxeboot/tftp kopieren und fertig sind wir - für den ersten Schritt. Den DHCP-Server und den inetd noch kurz mit der neuen Konfiguration vertraut machen (also known as durchstarten) und schon sollten die Maschinen per PXE den Debian Installer booten können.

Allerdings - zumindest mir - reicht das noch nicht. Für’s Debugging eignet sich noch ein Live-System, außerdem muß noch der Installer von FreeBSD mit in’s Boot-Menü.

Grade für Debugging hat sich bei mir grml bewährt.

grml is a bootable CD (Live-CD) originally based on Knoppix and nowadays based on Debian. grml includes a collection of GNU/Linux software especially for system administrator and users of texttools. grml provides automatic hardware detection. You can use grml (for example) as a rescue system, for analyzing systems/networks or as a working environment. It is not necessary to install anything to a harddisk; you don’t even need a harddisk to run it. Due to on-the-fly decompression grml includes about 2.1GB of software and documentation on the CD.

[grml]

Aus dem grml-ISO basteln wir eine NFS-Freigabe und laden zusätzlich noch die speziellen Files für den grml-Netboot.


# mkdir /opt/pxeboot/tftp/grml
# wget ftp://ftp.uni-erlangen.de/pub/mirrors/grml/grml_1.1.iso
# mount -o loop grml_1.0.iso /mnt/tmp/
# cp -r /mnt/tmp/* /opt/pxeboot/tftp/grml
# cp /mnt/tmp/boot/isolinux/minirt26.gz /opt/pxeboot/tftp/grml/boot/
# umount /mnt/tmp
# wget http://grml.org/terminalserver/grml_netboot_package_1.1.tar.bz2
# tar xvjpf grml_netboot_package_1.1.tar.bz2
# cp grml_netboot_package_grml_1.1/tftpboot/linux26 /opt/pxeboot/tftp/grml/boot/
# cp grml_netboot_package_grml_1.1/tftpboot/minirt26.gz /opt/pxeboot/tftp/grml/boot/
# cp grml_netboot_package_grml_1.1/tftpboot/memtest /opt/pxeboot/tftp/grml/boot/


Sowohl das ISO als auch den Inhalt von grml_netboot_package_1.1.tar.bz2 benötigen wir danach nicht mehr.

Die Datei /opt/pxeboot/tftp/pxelinux.cfg/default noch um den grml-Eintrag anpassen:

LABEL grml
 MENU LABEL ^GRML
 kernel grml/boot/linux26
 append ramdisk_size=24000 root=/dev/ram0 rw init=/etc/init nfsdir=Server-IP-oder-Name:/opt/pxeboot/tftp/grml/ nodhcp noprompt noeject apm=power-off nomce initrd=grml/boot/minirt26.gz vga=normal

Was jetzt noch fehlt, ist der NFS-Export von /opt/pxeboot/tftp/grml - aber auch das ist kein größeres Problem. Die Datei /etc/exports um die entsprechenden Einträge ergänzen und den NFS-Dienst ebenfalls neu starten.


/opt/pxeboot/tftp/grml/ * (ro,no_root_squash,no_subtree_check)
/opt/pxeboot/tftp/ * (ro,no_root_squash,no_subtree_check)


That’s it - jetzt ist auch grml über das Netzwerk startbar. Fehlt noch FreeBSD.

Leider ist der Aufwand bei FreeBSD etwas größer als bei Linux, denn für das Erstellen eines PXE-Images benötigt man ein funktionierendes FreeBSD-System und ein bootonly.iso.


# mdconfig -a -t vnode -f 7.0-RELEASE-i386-bootonly.iso -u1 ; mount -t cd9660 /dev/md1 /mnt/cdrom
# dd if=/dev/zero of=fbsd7R_i386.img bs=1k count=32k
# mdconfig -a -t vnode -f fbsd7R_i386.img -u0
# bsdlabel -w -B md0 auto; bsdlabel -A md0
# newfs -b 8192 -f 1024 /dev/md0a
# mount /dev/md0a /mnt/disk
# cp -R /mnt/cdrom/boot /mnt/disk/
# umount /mnt/disk
# umount /mnt/cdrom ; mdconfig -d -u0 ; mdconfig -d -u1
[nach /dev/rant]

Das entstandende Image fbsd7R_i386.img auf den PXE-Server kopieren, gzipen und in pxelinux.cfg/default mit eintragen.


LABEL fbsd7-i386
 MENU LABEL FreeBSD 7-RELEASE i386
 kernel memdisk
 append initrd=freebsd/fbsd7R_i386.img.gz harddisk noedd


Die Datei memdisk ebenfalls noch aus syslinux ins Verzeichnis /opt/pxeboot/tftp kopieren, denn die benötigt der FreeBSD Start-Vorgang. Auch FreeBSD hat einen AMD64-Zweig. Der wird entsprechend der Anleitung oben für i386 gebaut.

Das war’s - das Gröbste ist erledigt. Wem die Menüs noch nicht gefallen kann sich an syslinux noch ein bisselchen verkünsteln - Stichwort: vesamenu.c32.
Ich habe das ganze vor einer Weile für unser Büro-Netzwerk gebaut, und bin bisher sehr zufrieden. Wirklich geholfen haben mir die folgenden Postings, danke an die Autoren!

• PXE-Bootmenü für Debian-Installer und GRML
• Convert FreeBSD ISO image for PXE bootstrap
• pxelinux BSD installs

Ebenfalls ganz interessant ist ein Eintag von RoudyBob.NET, für alle, die versuchen Microsoft Virtual PC 2004 per PXE zu booten. Ohne ein spezielles Floppy-Image funktioniert das nämlich nicht.

Wer heute schon eine Version von Windows Server 2008 in den Händen hält kann sich glücklich schätzen, denn Server 2008 läuft wunderbar in einer Windows 2003 Active Directory.

Als domain member reicht der übliche Weg über die Computer-Verwaltung, und selbst für den Betrieb als Domain Controller sind nur wenige Handgriffe nötig. Sofern noch kein Forest existiert, auf einem der bestehenden DCs das Tool adprep ausführen und den Forest erstellen.

adprep /forestPrep
adprep /domainPrep

Um die Gruppenrichtlinen-Objekte noch zu aktualisieren:

adprep /domainPrep /gpprep

Sofern eine Server 2008 Installation später als read only DC arbeiten soll, noch zusätzlich

adprep /rodc

ausführen. Die Domain ist jetzt vorbereitet und dem Server 2008 kann die Rolle “Active Directory Controller” installiert werden. Funktioniert übrigens auch wunderbar mit dem Small Business Server 2003.

That’s it!

Sehr häufig werde ich gefragt, wie Subnetze im IPv4-Netz sinnvoll und vor allem richtig berechnet werden. Lasst Euch gesagt sein, so schwer ist das gar nicht! Im Grunde genommen, muß man sich’s nur richtig vorstellen, ab da reichen ein paar Finger zum zählen und die guten alten Zweierpotenzen.
Und dank der Hilfe von ipcalc ist die Erklärung sogar sehr angenehm zu lesen.

Für den Anfang schauen wir uns zunächst die privaten IP-Bereiche, sogenannte RFC1918-Netze an:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

Die RFC1918-Netz werden im Internet nicht geroutet, was bedeutet, daß hinter NAT-Gateways oder in rein internen Bereichen diese Netze ohne Genehmigung oder Ähnlichem genutzt werden dürfen. (Natürlich bitte trotzdem darauf achten, daß jede IP nur genau einmal im Netz vorkommen darf!)

Es gibt allerdings noch zwei Sonderfälle, die jedem Admin sehr häufig unterkommen werden:

• 127.0.0.0/8
• 169.254.0.0/16

Die folgenden Netze werde ich etwas ausführlicher erklären:

• 192.168.1.1/24
• 192.168.1.1/25
• 192.168.1.1/30
• 172.16.0.0/16
• 172.18.0.0/16
• 10.100.0.0/15
• 10.102.0.0/15
• 80.190.170.0/23
• 80.190.171.176/29

Sobald die Netze alle grob beschrieben sind, gibt’s noch ein paar allgemeine Hinweise.

10.0.0.0/8  [hoch]

Das größte private Subnetz ist 10.0.0.0/8. Wenn man sich die komplette Anzahl aller exitierenden IPs vorstellt, so ist ein /8 ein zweihundertsechsundfünfzigstel. Man stelle sich einen langen Strich als die gesammte Anzahl von existierenden IPs vor, und schneide ein zweihundertsechsundfünfzigstel davon ab. Das ist ein /8. /8-Netze wurden früher als Class-A bezeichnet, doch seit der Einführung von CIDR sollte man nicht mehr länger von Klassen sprechen.

172.16.0.0/12  [hoch]

Der nächste private IP-Block ist 172.16.0.0/12. Ebenfalls für die private Nutzung vorgesehen, umfasst dieser Block etwa eine Million IPs und enspricht damit einem sechtzehntel /8. Um die Klassen anzusprechen: ein /12 enthält insgesammt 16 Class-B Netze.
In den meisten Fällen werden aus 172.16.0.0/12 /16-Netze gemacht, in dem das komplette 172.16.0.0/12 in 16 Teile geschnitten wird (z.B. 172.16.0.0/16).

192.168.0.0/16  [hoch]

Der letzte private IP-Block ist 192.168.0.0/16 und entspricht damit einem zweihundertsechsundfünfzigstel /8. Der extrem lange Stich von eben, von dem wir ein zweihundertsechsundfünfzigstel abgebrochen haben? Dieses abgebrochene Teil brechen wir nochmals in 256 Teile. Jeder dieser Teile ist ein /16.
Ähnlich wie bei 172.16.0.0/12 geht man häufig dazu über den 192.168.0.0/16-Block in wieder 256 Teile zu brechen und /24 Netze aus dem 192.168.0.0/16-Bereich zu machen (z.B. 192.168.1.1/24).

127.0.0.0/8  [hoch]

Dies ist das sogenannte Loopback-Netz, was bedeutet, daß Pakete, die an eine der Adressen 127.X.X.X (X kann beliebig zwischen 0 und 255 gewählt werden) geschickt werden die Netzwerk-Hardware gar nicht verlassen, und das Betriebssystem automagisch auf sich selbst auflöst. Einfach mal versuchen, vielleicht funktioniert’s: http://127.0.0.1.

169.254.0.0/16  [hoch]

169.254.0.0/16 ist ein Spezialfall, bei dem sich der Admin - in den meisten Fällen - Gedanken machen sollte.

169.254.0.0/16 - This is the “link local” block. It is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server may not be found.

Ansonsten aber: genug Ausnahmen, jetzt rann ans Werk!

192.168.1.1/24  [hoch]

Aus den meisten DSL-Routern und sonstiger Home-Hardware fallen IPs im Stile von 192.168.1.1/24 raus, was den 192.168.0.0/16-Block zu einem beliebten Ziel für Mißverständnisse und doppelten IPs macht. Wir betrachten hier ein /24, also den zweihundertsechsundfünfzigsten Teil eines /16, was der zweihundertsechsundfünfzigste Teil eines /8 ist, was wiederum der zweihundertsechsundfünfzigste Teil der gesammten Menge an IPs ist. Da fühlt man sich doch plötzlich klein, oder?

192.168.1.1/24 ist ein IP-Netz mit 256 IPs, doch auch hier - wie üblich - sind die erste und die letzte IP reserviert. Die erste IP in jedem IP-Netz ist die Netzwerk-IP, in diesem Beispiel die 192.168.1.0, und die letzte mögliche IP wird als Broadcast-IP bezeichnet - hier die 192.168.1.255. Diese beiden IPs dürfen unter gar keinen Umständen einer Maschine zugeordnet werden. Beide haben spezielle Aufgaben, auf die ich aber an dieser Stelle nicht eingehen möchte.
Innerhalb dieses /24 sind also alle IP-Adressen von 192.168.1.1 bis 192.168.1.254 nutzbar.

192.168.1.1/25  [hoch]

Es kann der Fall sein, daß 192.168.1.1/24 für das geplante Netz schlichtweg zu groß ist. Wenn nur etwa 100 IPs benötigt werden, kann die Größe des Netzes wunderbar angepasst werden. Bitte nochmals zum Messer greifen, und einen sauberen Schnitt in der Mitte des 192.168.1.1/24 anbringen. Wir haben nun zwei Netze mit jeweils einem halben /24, also einem /25 gewonnen. 192.168.1.1/25 und 192.168.1.128/25. Ein /25 enthält noch 128 IPs. Zieht man auch hier wieder Netzwerk-IP und Broadcast ab, bleiben 126 nutzbare IPs.
Im großen Zusammenhang ist als ein /25 die Hälfte des zweihundertsechsundfünfzigsten Teil eines /16, was der zweihundertsechsundfünfzigste Teil eines /8 ist, was wiederum der zweihundertsechsundfünfzigste Teil der gesammten Menge an IPs ist. Aber es geht noch kleiner!

192.168.1.1/30  [hoch]

Das Netz 192.168.1.1/30 ist schon wirklich sehr klein, denn es enthält noch genau 4 IPs. Solche Netze eignen sich wunderbar um genau zwei Geräte miteinander zu verbinden. Stichwort: Transfer-Netz. Genau zwei nutzbare IPs, also genau Platz für zwei Geräte. Ein /30 ist der vierundsechzigste Teil eines /24.

172.16.0.0/16  [hoch]

Die nächsten beiden werden wieder einfach, ich versprech’s. 172.16.0.0/16 ist ein /16, also einer der 256 Teile des /8 von oben. Der nutzbare Bereich dieses Netzes - ohne es weiter zu unterteilen - ist also 172.16.0.1 bis 172.16.255.254.

Wichtig ist hierbei zu verstehen, daß abgesehen von Netzwerk-IP (172.16.0.0) und Broadcast (172.16.255.255) jede andere IP nutzbar ist, also auch z.B. 172.16.13.0 oder 172.16.82.255. Hier liegt es im Sinne des Admins und seines ästhetischen Empfinden ob diese IPs genutzt werden oder nicht. Ich persönlich nutze sie nicht.

172.18.0.0/16  [hoch]

Wie eben schon 172.16.0.0/16 ist auch 172.18.0.0/16 an sich ein triviales Netz. Die Netzwerk-Maske ist identisch zu 172.16.0.0/16 und das Netz ist auch genauso groß. Nichts desto trotz ist es ein komplett eigenes Netz, und hat mit 172.16.0.0/16 nichts zu tun. Auch wenn beide Netze Teilstücke von 172.16.0.0/12 sind.

10.100.0.0/15  [hoch]

Alle Leser noch anwesend? Dann weiter. 10.100.0.0/15 ist kleiner als ein /8 jedoch größer als ein /16. Genau genommen doppelt so groß wie ein /16. Der nutzbare Bereich erstreckt sich also von 10.100.0.1 bis 10.101.255.254. Mit etwa 130000 nutzbaren IPs sollt dieses Netz groß genug sein um den DSL-Router, den kleinen iMac und die X-Box anzusprechen.
Man stelle sich nochmals den langen Strich vom /8 vor. Um /16-Netze zu erhalten, haben wir diesen Strich in 256 Teile zerschnitten. Fuer /15 zerschneiden wir ihn nur in 128 gleich große Teile.

10.102.0.0/15  [hoch]

10.100.0.0/15 war nicht schwer, also sollte 10.102.0.0/15 auch nicht schwer werden. Es ist nämlich einfach nur das nächste /15, also der nächste hundertachundzwanzigstel Fetzen des /8. Worauf ich hinaus will ist folgendes:
Wenn in einem Unternehmen 10.100.0.0/15 und 10.102.0.0/15 verwendet werden, und eines Tages den Admins die Anforderung eines einzelnen großen Netzes in der Inbox landet, ist das in diesem Falle sehr einfach, da beide Netze zu einem großen aggregiert (zusammengefasst) werden können. Beide /15 werden zu einem großen /14, nämlich zu 10.100.0.0/14, und das nur durch die Änderung der Netzwerk-Masken auf allen Teilnehmern des Netzes. Dieses /14 ist dann voll nutzbar, angefangen bei 10.100.0.1 bis schließlich 10.103.255.254. Das umfasst in etwa 260000 IPs.

80.190.170.0/23  [hoch]

Ein konkreteres Beispiel, denn alles was hier steht bezieht sich nicht nur auf RFC1918-Netze. 80.190.170.0/23 ist ein reelles Netz im Internet, zufälliger Weise der Firma Interdose zugeordnet. Es enthält insgesammt 512 IP-Adressen von denen - ohne weitere Aufteilung - 510 nutzbar sind. Der nutzbare Bereich ist also von 80.190.170.1 bis 80.190.171.254. Auch hier wieder sind 80.190.170.255 und 80.190.171.0 theoretisch nutzbar. 80.190.170.0/23 ist der hundertachtundzwanzigste Teil von 80.190.0.0/16.
Im nächsten Beispiel greifen wir ein Teil dieses Netzwerks noch weiter an.

80.190.171.176/29  [hoch]

Für den NoName e.V. haben wir ein /29 reserviert. Ein /29 enthält insgesammt 8 IPs von denen 6 nutzbar sind. Die IP-Adresse 80.190.171.179 ist eine der IPs aus diesem Netz, und damit ein Teil von 80.190.171.176/29.

Subnetze sollten jetzt keine unlösbare Herausforderung mehr sein. Doch in allen Beispielen gingen wir davon aus, dass immer in exakt gleich große Teile zerschnitten wird. Man kann aber z.B. aus einem /24 auch ein /25, ein /26 und zwei /27 machen. Beim Beispiel 10.102.0.0/15 sprach ich vom Aggregieren von Netzen, also dem Zusammenfassen kleinerer Netze zu einem großen.
Unterschiedlich große Teile erreicht man z.B. über den Umweg, daß erst das vorhandene Netz (bleiben wir beim /24) in die größe des kleinsten benötigten Netzes aufgeteilt wird - hier ein /28. Außerdem benötigen wir noch drei Netze der Größe /27 und ein /25. Das /24 zerteilen wir in 16 Teile, um das /28 zu erhalten. Zwei /28 ergeben ein /27, also können wir die drei /27 erstellen, in dem wir jeweils zwei /28 zusammenfassen - und das genau sechs mal. Ein /25 besteht aus zwei /26, also aus vier /27. Aus acht /28 können wir also das gewünschte /25 aggregieren. Von den 16 Teilen verbleibt also am Ende noch genau ein /28 übrig, der Rest ist zu den benötigten Netzen aggregiert worden. Eigentlich gar nicht so schwer, oder?

Dann bleibt ja nur noch die Frage der richtigen Netzwerk-Maske offen. Jedes Mal ipcalc anwerfen ist auch nicht die optimale Methode, aber hier kommen die Zweierpotenzen ins Spiel. Und das schönste: an dieser Stelle darf sogar wieder in den Klassen A, B und C gedacht werden.
Ein /8 hat die Netz-Maske 255.0.0.0, ein /16 bringt 255.255.0.0 mit sich und /24 entspricht 255.255.255.0. Sobald die Klassen-Netze weiter unterteilt werden, ändern sich natürlich die Stellen der Maske, an denen sich das Netz ändert. Was war aber von der IT anders zu erwarten? Es Ändert sich immer nach dem gleichen Muster. Die nachfolgende Tablelle zeigt den Werdegang der Maske an Hand des Weges von einem /24 zu einem /16:

Die Änderungen sind immer linear, was so viel bedeutet wie, daß sich beim Weg von einem /16 zu einem /8 die gleichen Änderungen ergeben, wenn auch eine Stelle weiter vorne in der Maske. Man brauch sich also eigentlich nur die folgenden Zahlen merken, und die Stelle der Maske. Ab da kann gezählt werden:

• 255
• 254
• 252
• 248
• 240
• 224
• 192
• 128
• 0

Oder die umgekehrte Reihenfolge, falls das Netz vekleinert werden soll:

• 0
• 128
• 192
• 224
• 240
• 248
• 252
• 254
• 255

War doch eigentlich gar nicht so schwer, oder?
Für Fragen und Anregungen bin ich natürlich immer offen. Ansonsten: viel Spaß mit den Netzen. Notfalls: ipcalc hilft!

Quick Reference Cards muß man nicht mehr länger suchen.

Sortiert nach Programmierung, Administration, Datenbanken und Editoren. Ein Blick wert.

Update: Seit ein paar Tagen ist der Link offline.

Ist zwar etwas “gewöhnungsbedürftig” gemacht, aber echt sehenswert, was ZFS angeht.

Und ja, es ist Werbung…
[Update, wer auf FreeBSD steht.]

Dominik hat das Wochenende mit einem kleinen Projekt von uns verbracht, woran jeder Admin seine Freude haben wird könnte.

Oft sind es die kleinen Tools, die die tägliche Arbeit mit dem Computer leichter machen.

Was bisher schon läuft:

• Punycode Converter
• PING
• TraceRoute

Geplant ist noch mehr, vor allem schwebt es mir noch vor dem Ganzen IPv6 bei zu bringen. Expect more to .com!

Ob IPv6 wirklich Internet-NG ist sei mal in den Raum gestellt. IPv6 macht Spass und bringt viele Vorteile, nur leider (?) gibt es noch nahezu keine Provider, die natives IPv6 aus dem DSL-Anschluss fallen lassen.

Wer trotzdem in den Genuss von IPv6 kommen will, dem sei SixXS.net an’s Herz gelegt. SixXS bietet IPv6 per Tunnel zu jedem beliebigen IPv4-Endpunkt an. Auch die statische IP-Adresse ist nicht noetig, da ueber ein Heartbeat-Protokoll ein Tunnel genauso wie ueber eine statische IP aufgebaut werden kann.

SixXS (Six Access) is a free, non-profit, non-cost service for Local Internet Registries (LIR’s) and endusers. The main target is to create a common portal to help company engineers find their way with IPv6 networks deploying IPv6 to their customers in a rapid and controllable fashion. To reach these targets we are providing a whitelabel IPv6 Tunnel Broker and Ghost Route Hunter, an IPv6 route monitoring tool and various other services to help out where needed.

Bitte aber eine Sache beachten: wer mit IPv6 rumspielt sollte aufpassen. IPv6-Adressen sind global geroutet; da sollte eine Firewall ins Spiel! ip6tables sollte es schon mindestens sein.