Benutzer-Werkzeuge

Webseiten-Werkzeuge


Übersetzungen dieser Seite:
de:ripng

IPv6 Routing mit RIPng

Wenn mehrere Edge-Router in einem LAN auftauchen, sollten sich sich über die Routen zu ihren „Wolken“ unterhalten, damit man alle Nodes erreichen kann.

In diesem einfachen Fall lässt sich RIPng (der IPv6 Nachfolger von RIPv2) verwenden, da die bekannten Probleme von RIP (maximal 16 Hops, „count to infinity“, …) hier keine große Rolle spielen.

BIRD Routing Daemon

Da Quagga immer noch zu groß für kleine Systeme ist kommt BIRD eher zum Zug.

Ich dokumentiere hier später, vorerst sei gesagt, dass IPv6 Router Advertisments mit dem aktuellen Debian Paket nicht funktioniert. Daher habe ich die Git Version mit zwei Patches aus den Soucen kompiliert.

bird1.patch

bird2.patch

git clone git://git.nic.cz/bird.git
patch -p1   < ../bird1.patch
patch -p1   < ../bird2.patch
autoconf

Die Konfiguration ist erfrischend einfach:

# bird.conf
#
# dynamic routing configuration
#
# v0.1 2011-10-21 GS (goesta@smekal.at)

# global parameters

log syslog all;
debug protocols { routes, events, packets };

router id 192.168.0.34;

## routing protocols

# device parameters
protocol device {
  scan time 10;
  primary "eth0" 2001:858:5:bb8:a00:27ff:fe7b:12b1;
  primary "eth1" 2001:858:5:bee::1:1:1;
}

protocol direct{
  interface "*";
}

# kernel routing table
protocol kernel {
  scan time 10;
  persist yes;
  learn yes;
  import all;
  export all;
}

# router advertisments
protocol radv {
  interface "eth1";
}

# dynamic routing using RIPng
protocol rip{
  authentication none;
#  authentication md5;
#  password "verysecure";
  honor neighbor;
  import all;
  export all;
  interface "eth0" { metric 1; };
}

Binary verkleinern

Eine angepasste Konfiguration erreicht man durch ein paar Optionen für das configure Script:

root@edge01:/usr/src/bird-1.3.4# ./configure --prefix=/usr/local --enable-ipv6 --with-protocols=device,kernel,radv,rip
[...]
BIRD was configured with the following options:
	Source directory:	.
	Object directory:	obj
	Iproute2 directory:	/etc/iproute2
	System configuration:	./sysdep/cf/linux-v6.h
	Debugging:		no
	Routing protocols:	radv rip
	Client:			yes

Für das Digi ME9210 HW-Module konfiguriert man bird mittels:

./configure  --host=arm-linux --build=i386-linux --prefix=/home/<user>/Digi/DigiEL-5.2/usr --enable-ipv6 --with-protocols=radv,rip  --disable-client

BIRD was configured with the following options:
        Source directory:       .
        Object directory:       obj
        Iproute2 directory:     /etc/iproute2
        System configuration:   ./sysdep/cf/linux-v6.h
        Debugging:              no
        Routing protocols:      radv rip
        Client:                 no

… nun kann man noch erwägen, ob man den Client wirklich braucht und gegebenenfalls –disable-client dazu fügen.

Nach der üblichen Installationsprozedur

root@edge01:/usr/src/bird-1.3.4# make all && make install

kann man das Ergebnis bestaunen:

BIRD mit allen Protokollen

-rwxr-xr-x 1 root root 324K Oct 21 16:05 /usr/local/sbin/bird6
-rwxr-xr-x 1 root root  23K Oct 21 16:05 /usr/local/sbin/birdc6

gobo@edge02:~$ ps v -C bird6
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
 2010 pts/0    S+     0:00      3     0  2124   944  0.3 /usr/local/sbin/bird6 -

BIRD mit RIP und RAdv

-rwxr-xr-x 1 root root 194K Oct 23 21:01 /usr/local/sbin/bird6
-rwxr-xr-x 1 root root  21K Oct 23 21:01 /usr/local/sbin/birdc6

gobo@edge01:~$ ps v -C bird6
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
 4656 pts/0    S+     0:00      0     0  1992   908  0.3 /usr/local/sbin/bird6 -

RIPng für Linux = Quagga

Der Quagga Routing Daemon spricht unter Linux alle wichtigen Routingprotokolle. Man kann aber die unerwünschten bei der Konfiguration auch abschalten (oder gar nicht erst kompilieren FIXME).

Architektur

Quagga verfügt über mehrere Komponenten:

  • Zebra ist die Schnittstelle zu den Routingtabellen des Kernel und kümmert sich um die verschiedenen Routing-Updates
  • Routing-Daeomons vermitteln zwischen den Routern und senden/empfangen die Änderungen. Es gibt einen Daemon für jedes Routingprotokoll:
    • ripd für RIPv1 und RIPv2
    • ripngd für RIPng
    • ospfd für OSPF
    • ospf6d für OSPF IPv6
    • bgpd für BGP
    • isisd für IS-IS

Die einzelnen Daemons sind eigene Prozesse und kommunizieren mit dem zebra über Sockets.

Wir beschäftigen uns hier nur mit zebra und ripngd.

Konfiguration

In meinem Testnetz habe ich zwei (virtuelle) Router, edge01 und edge02, die zwischen dem LAN und einem virtuellen Netz vermitteln. Im virtuellen Netz gibt es einen Client node01. Dieser bezieht sein IPv6 Präfix von den Routern.

Da die beiden Router im virtuellen Netz ein anderes Präfix verkünden (derzeit noch per RADVD FIXME), hat node01 zwei global unicast Adressen.

Die Router können die Node unter der jeweils „anderen“ IPv6 Adresse über den jeweils anderen Router erreichen.

zebra.conf

hostname edge01
password quagga
enable password quagga
log file /var/log/quagga/zebra.log debugging

interface eth0
  ipv6 address 2001:858:5:bb8:0:1:1:1/64
  no ipv6 nd suppress-ra

interface eth1
  ipv6 address 2001:858:5:bee:0:1:1:1/64
  no ipv6 nd suppress-ra

ipv6 forwarding
ipv6 route 2001:858:5:bee::/64 eth1

ripngd.conf

hostname edge01
password quagga
enable password quagga
log file /var/log/quagga/ripngd.log debugging

router ripng
network eth0
network eth1
no passive-interface eth0
redistribute static

radvd.conf

interface eth1
{
  AdvSendAdvert on;
  prefix 2001:858:5:bee::/64
  {
    AdvOnLink on;
    AdvAutonomous on;
  };
};

Known Bugs

Mein Setup hat noch ein paar Fehler:

  1. ich brauche den RADVD, weil ich dem Zebra noch nicht beigebracht habe, die Präfixe zu verteilen
  2. im LAN wird ein zusätzliches Defaultgateway verteilt, dafür erhalten die PCs keine Route in das virtuelle Netz
  3. habe ich sicher noch nicht alle Fehler gefunden ;-)

pseudodynamisches Routing

Weil der Quagga für Digi Module zu groß ist und der RADVD zwar Routen hinausposaunen kann, die Clients das aber ignorieren, versuchen wir sowas mit einfacheren Mitteln.

YARDS

yet another routing distribution script

Mit einem Shellscript kann man versuchen seine Route anderen Membern mitzuteilen. Ziel ist es das alle Router alle PAN Prefixe kennen.

Annahmen

  alle Knoten verwenden das gleiche Unique Local Address Prefix
  alle Knoten finden über broudcast ping ihre member
  alle knoten haben einen route-usr
  route-usr hat auf allen Knoten das gleiche SSH Schlüsselpaar – das ist gefährlich!
  route-usr darf sich auf allen Knoten per SSH und preshared Keys einloggen – das ist noch gefährlicher

Member - Member mit SCP

Mit einem Shellscript kann man versuchen seine Konfiguration allen Members mitzuteilen. Danach kennen alle Member alle PAN Prefix Routen.

Ablauf

Wenn ein Knoten bootet geht er wie folgt vor:

  am LAN Interface eine temporäre IPv6 Adresse mit dem Unique Local Prefix und der MAC Adresse erzeugen
  mit Ping versuchen Member Rooter zu erreichen
      bei Erfolg IP behalten und PAN-Prefix-Route per SSH an andere Member senden

Nach einer Zeitspanne X wird versucht neuen Membern die Information der eigenen PAN-Prefix-Route per scp zukommen zu lassen.

Script

In Bash sieht das so aus:

#!/bin/bash
 
# YARDS
# yet another routing distribution script 
# ipv6_routing
#
# v0.1 2011-10-12 Harald Pichler (harald@the-develop.net)
#
# simple (and maybe stupid) way to find member router and copy the routes
 
# License:
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# The software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 
# global defaults on all nodes (from unique local address range)
GLOBAL_PREFIX='fd00:1:feed:bee5'
GLOBAL_MASTER_IP="${GLOBAL_PREFIX}::f001"
GLOBAL_SSH_PUB_KEY='/etc/ssl/keys/global_router.pub'
GLOBAL_SSH_PRIV_KEY='/etc/ssl/keys/global_router'
 
# local LAN information
LAN_IF='eth0'
 
# local PAN information (should be read from the environment ... sometimes
PAN_IF='tun0'
PAN_PREFIX='2001:858:5:bee::/64'
 
# set private IP (dirty hack! ... no perl, no sed, ...?)
LAN_MAC=`ifconfig $LAN_IF | grep HWaddr | cut -c 39- | tr -d :`
LAN_MAC_1=`echo $LAN_MAC | cut -c1-4`
LAN_MAC_2=`echo $LAN_MAC | cut -c5-6`
LAN_MAC_3=`echo $LAN_MAC | cut -c7-8`
LAN_MAC_4=`echo $LAN_MAC | cut -c9-`
LOCALPART="$LAN_MAC_1:${LAN_MAC_2}ff:fe$LAN_MAC_3:$LAN_MAC_4"
 
LAN_TEMP_IP="$GLOBAL_PREFIX:$LOCALPART"
LAN_IP="fe80::$LOCALPART"
 
# temporary set up LAN
if ifconfig $LAN_IF add $LAN_TEMP_IP/64
then
  echo "LAN IP $LAN_IP temporarily set on $LAN_IF ..."
else
  echo "error configuring LAN IP $LAN_IP on $LAN_IF!"
fi
 
# find member nodes
#todo !!!!!!

To Do

  wichtige Parameter müssen via Environment geholt werden
  Privilegien des SSH-Konstrukts so wiet wie möglich einschränken

Probleme

  die SSH Hostkeys müssen interaktiv akzeptiert werden FIXME (SSH Client Parameter?)
  das ganze SSH Konstrukt ist inherent unsicher
  die Routen werden nicht an “normale” Clients verteilt (kennen nur die default routen)

Master - Member mit SCP

Mit einem Shellscript kann man versuchen eine Master - Member Konfiguration aufzubauen. Dabei gibt es einen Master Router, der alle PAN Prefixe kennt und keinen, einen oder mehrere Member, die dem Master ihre Prefixe mitteilen.

Annahmen

  1. alle Knoten verwenden das gleiche Unique Local Address Prefix
  2. alle Knoten kennen die voreingestellte IP des Master-Knoten
  3. root hat auf allen Knoten das gleiche SSH Schlüsselpaar – das ist gefährlich!
  4. root darf sich auf allen Knoten per SSH und preshared Keys einloggen – das ist noch gefährlicher

Ablauf

Wenn ein Knoten bootet geht er wie folgt vor:

  1. am LAN Interface eine temporäre IPv6 Adresse mit dem Unique Local Prefix und der MAC Adresse erzeugen
  2. mit Ping versuchen den Master Router zu erreichen
    • bei Erfolg IP behalten und PAN Prefix per SSH an Master senden
    • sonst selbst zum Master werden → Default Master IP am LAN Interface setzen

Script

In Bash sieht das so aus:

#!/bin/bash
 
#
# ipv6_routing
#
# v0.1 2011-10-12 GS (goesta@smekal.at)
#
# simple (and maybe stupid) way to find fellow router
 
# License:
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# The software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 
# global defaults on all nodes (from unique local address range)
GLOBAL_PREFIX='fd00:1:feed:bee5'
GLOBAL_MASTER_IP="${GLOBAL_PREFIX}::f001"
GLOBAL_SSH_PUB_KEY='/etc/ssl/keys/global_router.pub'
GLOBAL_SSH_PRIV_KEY='/etc/ssl/keys/global_router'
 
# local LAN information
LAN_IF='eth0'
 
# local PAN information (should be read from the environment ... sometimes
PAN_IF='eth1'
PAN_PREFIX='2001:858:5:bee::/64'
 
# set private IP (dirty hack! ... no perl, no sed, ...?)
LAN_MAC=`ifconfig $LAN_IF | grep HWaddr | cut -c 39- | tr -d :`
LAN_MAC_1=`echo $LAN_MAC | cut -c1-4`
LAN_MAC_2=`echo $LAN_MAC | cut -c5-6`
LAN_MAC_3=`echo $LAN_MAC | cut -c7-8`
LAN_MAC_4=`echo $LAN_MAC | cut -c9-`
LOCALPART="$LAN_MAC_1:${LAN_MAC_2}ff:fe$LAN_MAC_3:$LAN_MAC_4"
 
LAN_TEMP_IP="$GLOBAL_PREFIX:$LOCALPART"
LAN_IP="fe80::$LOCALPART"
 
# temporary set up LAN
if ifconfig $LAN_IF add $LAN_TEMP_IP/64
then
  echo "LAN IP $LAN_IP temporarily set on $LAN_IF ..."
else
  echo "error configuring LAN IP $LAN_IP on $LAN_IF!"
fi
 
# find master node
if ping6 -I $LAN_IF -c 3 $GLOBAL_MASTER_IP >/dev/null 2>/dev/null
then
  # we are not alone!
  echo "got response from $GLOBAL_MASTER_IP!"
  echo "attempting to send prefix $PAN_PREFIX ..."
  # send PAN prefix
  if ssh -i $GLOBAL_SSH_PRIV_KEY $GLOBAL_MASTER_IP route -A inet6 add $PAN_PREFIX gw $LAN_TEMP_IP
  then
    echo "success! we keep the local IP."
  else
    echo "failed to copy routing entry!"
  fi
else
  # we are the master node
  echo "no response ... removing temporary IP ..."
  if ifconfig $LAN_IF del $LAN_TEMP_IP/64
  then
    echo "... done"
  else
    echo "failed to remove $LAN_TEMP_IP from $LAN_IF!"
  fi
  echo "setting global master IP ..."
  if ifconfig $LAN_IF add $GLOBAL_MASTER_IP/64
  then
    echo "done. we are now $GLOBAL_MASTER_IP"
  else
    echo "failed to set ip $GLOABL_MASTER_IP!"
  fi
fi

To Do

  • wichtige Parameter müssen via Environment geholt werden
  • Privilegien des SSH-Konstrukts so wiet wie möglich einschränken

Probleme

  1. die SSH Hostkeys müssen interaktiv akzeptiert werden FIXME (SSH Client Parameter?)
  2. das ganze SSH Konstrukt ist inherent unsicher
  3. die Routen werden nur vom Member zum Master verteilt → der Master kann zwar alle PANs erreichen, die Member aber nicht
  4. die Routen werden nicht an „normale“ Clients verteilt

offene Fragen

  • gibt es am Digi eine BASH? Das Script sollte aber unter der SH auch laufen - BASH spezifischer Code wurde vermieden
BusyBox v1.15.2 (2011-05-24 16:33:03 CEST) built-in shell (ash)
  • gibt es am Digi sed? Das könnte die MAC-Bastelei vereinfachen
This is not GNU sed version 4.0
  • vermutlich ist am Digi ein Dropbear installiert - kann der die Rechte einschränken?
Dropbear sshd v0.52
  • gibt es UIDs am Digi?
/ # id
uid=0(root) gid=0(root) groups=0(root)
/ # cat /etc/group
root:*:0:
www-data:*:33:
users:*:100:
nogroup:*:65534:
_ntp:x:501:

würde sagen ja (H.P.)

/ #             
de/ripng.txt · Zuletzt geändert: 2012/03/15 13:54 von wikisysop