Fedora 10 als PV6 Router

Zum Routen brauchen wir zwei Dinge: Routing und den Router Advertisement Daemon damit die anderen Rechner auch wissen, daß wir routen.

Das Routing anschalten:

[root@nass]# vi /etc/sysconfig/network
IPV6FORWARDING=yes

Anschließend mit yum install radvd den Daemon installieren und die /etc/radvd.conf anpassen. Hier müssenwir unsere lokalen IP-Adressen und Netze eintragen:

interface eth0
{
    AdvSendAdvert on;
       MinRtrAdvInterval 10;
       MaxRtrAdvInterval 30;
    AdvHomeAgentFlag off;
#
# example of a standard prefix
#
    prefix 2001:6f8:10ea::1/64
    {
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr on;
    };
        RDNSS 2001:6f8:10ea::1
        {
                AdvRDNSSPreference 8;
                AdvRDNSSOpen on;
                AdvRDNSSLifetime 200;
        };
};

Hier müssen wir die inneren Interface (also eth0 und nicht sixxs benutzen), da nur diese über das LAN für die anderen Rechner erreichbar sind. Anschließend einmal den radvd Dienst durch starten.

Mit radvdump -d 5 kann man dem Dienst zuschauen. Nach einigen Sekunden sollten auf den anderen Rechnern im Netz die Router-Advertisments ankommen:

Fedora 10 mit Sixxs IPV6-Tunnel

Wer keinen echten IPV6-Provider hat, kann sixxs als Tunnel-Betreiber benutzen, klappt prima.

yum install aiccu

Für den Tunnel brauchen wir drei Angaben von Sixxs in der /etc/aiccu.conf

#username
#password
#tunnel_id Txxxx

Wenn der Tunnel läuft sollte ein ifconfig etwa so aussehen:

eth0      Link encap:Ethernet  Hardware Adresse 00:0C:29:31:CB:15 
          inet Adresse:192.168.0.220  Bcast:192.168.0.255  Maske:255.255.255.0
          inet6 Adresse: 2001:6f8:10ea::1/64 Gültigkeitsbereich:Global
          inet6 Adresse: fe80::20c:29ff:fe31:cb15/64 Gültigkeitsbereich:Verbindung

sixxs     Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet6 Adresse: 2001:6f8:900:95d::2/64 Gültigkeitsbereich:Global
          inet6 Adresse: fe80::4f8:900:95d:2/64 Gültigkeitsbereich:Verbindung
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1280  Metric:1

Die 2001 sind die öffentlichen Adressen, die fe80 sind die link-lokalen (im LAN). Außerdem haben wir ein neues Interface sixxs, welches der Tunnel ist.

Ein kleiner Test:

[root@nass network-scripts]# ping6 ipv6.google.com
PING ipv6.google.com(2001:4860:0:1001::68) 56 data bytes
64 bytes from 2001:4860:0:1001::68: icmp_seq=1 ttl=57 time=61.2 ms
64 bytes from 2001:4860:0:1001::68: icmp_seq=2 ttl=57 time=62.0 ms
64 bytes from 2001:4860:0:1001::68: icmp_seq=3 ttl=57 time=60.8 ms
^C
— ipv6.google.com ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2415ms
rtt min/avg/max/mdev = 60.835/61.371/62.004/0.522 ms
[root@nass network-scripts]#

Wenn es klemmt,könnte es sein, daß ip6tables die Pakete verwirft:

[root@nass network-scripts]# ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination       

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination       

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination       
[root@nass network-scripts]#

SLAC: Zusammenfassung

Die SLAC hat sich wieder einmal gelohnt, da gab es einige wirklich interessante Vorträge.

Auf dem Rechtstag genau vorher waren leider einige Vorträge mit dem Vorjahr identisch, die Themen waren trotzdem interessant, aber halt schon mal gelaufen.

Noch mal SLAC

Holger Uhlig räumte einige Vorurteile über die verschiedenen RAID-Level (Performance, Zuverlässigkeit) auf. Schön kompakt zusammengefasst:

Und gleich weiter beim Thema Storage: Marus Schreier stellte ZFS vor. Ein wirklich beeindruckendes Dateisystem, sowas fehlt Linux noch:

SLAC: Ein ganz unruhiger Zeitgenosse

Selbst schuld, wer nicht stillhalten kann bekommt ein unscharfes Photo: Stefan Semmelrogge durfte seinen 1 Tages Workshop Linux Systemmonitoring in 90 Minuten quetschen. Wie zu erwarten überzog er natürlich kräftig und hörte auch erst auf, nachdem die ersten Leute Angst um ihr Abendessen hatten:

Aber trotz des kurzen Zeitrahmen doch interessant: Wer kennt schon die genaue Bedeutung von netstats TIME_WAIT und CLOSE_WAIT ?