Opérateur réseau alternatif

Howto NanoBSD quagga router

Le Gitoyen a fait le choix du routage libre, avec quagga pour son AS. Pour répondre à des besoins d’industrialisation de son backbone et de standardisation de ses routeurs, nous avons mis en place NanoBSD sur nos routeurs de bordure. Nous vous proposons dans les lignes qui suivent l’implémentation que nous en avons faite en justifiant chacun des choix techniques.

Nous avons choisis NanoBSD car il permet de générer des images systèmes de FreeBSD adaptés à des applications pour une utilisation sur un périphérique Flash. NanoBSD est particulièrement adapté pour réaliser des équipements dédiés qui fonctionneront sur un système de fichier principalement en lecture seule. NanoBSD offre les fonctionnalités suivante :
- les paquets de FreeBSD fonctionneront de façon identique sous NanoBSD,
- toutes les fonctionnalités de FreeBSD sont disponibles sous NanoBSD,
- tout est en lecture seule dès le démarrage, il n’est pas dangereux de débrancher l’alimentation électrique, il ne sera jamais nécessaire de lancer un fsck après un redémarrage imprévu du système,
- NanoBSD est simple à mettre en oeuvre et offre une souplesse de configuration permettant de générer des images systèmes sur mesure repondant à des jeux de contraintes divers.

Ainsi pour générer une clef routeur pour un routeur nous lançons :


~# /usr/src/tools/tools/nanobsd/nanobsd.sh -c nom_du_routeur.conf

Le fichier nom_du_routeur.conf ne comporte que la géométrie du disque, obtenue via :


[root@x-ray ~]# diskinfo -v /dev/da0
/dev/da0
       512             # sectorsize
       2071986176      # mediasize in bytes (1.9G)
       4046848         # mediasize in sectors
       251             # Cylinders according to firmware.
       255             # Heads according to firmware.
       63              # Sectors according to firmware.

donnera un fichier x-ray.conf du type :


#!/bin/sh
# vim:syntax=sh filetype=sh
set -e

. generic.conf
# The drive name of the media at runtime
NANO_DRIVE=da0

# Target media size in 512 bytes sectors
NANO_MEDIASIZE=4046848
NANO_HEADS=255
NANO_SECTS=63

le fichier

Zip - 1.7 ko
generic.conf

contient notre vrai configuration NanoBSD. Sa seule spécificité au regard du man nanobsd que vous trouverez sur FreeBSD est la commande add_port. add_port nous permet de compiler les paquets dans l’environnement cible de la clef, ce qui garantie la cohérence globale des outils et du système. A sa lecture, vous verrez que nous ajoutons en plus de quagga des utilitaires : pstree, screen, mtr, rsync, dmidecode... Nous utilisons aussi un kernel correspondant à nos équipements :

Zip - 4.6 ko
Configuration du Noyau

. Rien d’extraordinaire sinon l’activation du firewall ipfw que nous utilisons pour l’accounting, le polling pour les interface em (Intel pro 1000), et la présence de carp (Common Access Redundancy Protocol).

Une fois notre image compilé il nous reste à installer les configurations de bases. Pour cela nous avons developpé un scripts :

Zip - 1.2 ko

Il suffit donc de modifier la fstab de la machine de build en ajoutant :


/dev/da0s3 /cfg ufs     rw              2       2

ensuite lancer


mkdir /cfg
save_cfg -g <routeur-name>

Ce script en -g (get) appelle le script suivant sur la machine qui conserve les configurations dans svn, afin de conserver les droits et les permissions nous passons par fsvs.

A noter que par la suite save_cfg se trouve sur les routeurs et que nous l’utilisons pour sauvegarder /etc vers /cfg (donc de la ram vers l’image pour le prochain reboot) ainsi que pour commiter les modification de /cfg vers notre svn est ainsi conserver un historique des fichiers de configurations de nos routeurs.


#!/bin/sh

# set -x


# Need only One argument
if [ $# != 1 ]
then
 echo " FATAL : Please launch $0 routername.gitoyen.net"
 exit 255
fi

# Verify that a configuration for this router exist
[ $(svn list  https://TODEFINE/svn/ | grep "^$@/$") ] || exit 255

# Should be launch by root or in fakeroot to keep permissions and owner
if [ "`id -u`" != "0" ]
then
 fakeroot $0 $@
 exit
fi

TMP_DIR=/tmp/$$.cfg_restore

mkdir $TMP_DIR
cd $TMP_DIR
mkdir common specific
/usr/bin/fsvs checkout common https://TODEFINE/svn/common > /dev/null || exit 255
/usr/bin/fsvs checkout specific https://TODEFINE/svn/$@/cfg > /dev/null || exit 255
/usr/bin/rsync -a specific/ cfg || exit 255
/usr/bin/rsync -a common/ cfg || exit 255
/bin/tar c cfg
rm -rf $TMP_DIR

Nous avons fait le choix de faire une distinction entre les fichiers communs à tous les routeurs (common) et specifique à chacun. ci dessous la liste des fichiers que nos routeurs ont en communs.


./zprofile
./zshenv
./pwd.db
./group
./services
./ntp.conf
./mail/aliases.db
./mail/aliases
./ssh/authorized_keys
./ssh/ssh_config
./ssh/sshd_config
./ssh/id_dsa_savecfg
./zlogin
./daily.local
./periodic.conf
./inetd.conf
./passwd
./zlogout
./resolv.conf
./host.conf
./master.passwd
./syslog.conf
./network/README
./network/.reseaux-statiques
./network/.clients
./network/.reseaux-bgp
./network/.attribution-membres
./network/freebsd_iptables.sh
./network/.reseaux-membres
./network/local-parameters
./network/custom-firewall
./spwd.db
./ttys
./localtime
./zshrc

et ci dessous la liste des fichiers qui sont spécifiques :


./nsswitch.conf
./rc.conf
./opiekeys
./local/quagga
./local/quagga/bgpd.conf
./local/quagga/zebra.conf.sav
./local/quagga/bgpd.conf.sav
./local/quagga/ospf6d.conf.sav
./local/quagga/ospfd.conf
./local/quagga/ospf6d.conf
./local/quagga/zebra.conf
./local/quagga/ospfd.conf.sav
./ssh/ssh_host_rsa_key.pub
./ssh/ssh_host_dsa_key.pub
./ssh/moduli
./ssh/ssh_host_dsa_key
./ssh/ssh_known_hosts
./ssh/ssh_host_key.pub
./ssh/ssh_host_key
./ssh/ssh_host_rsa_key
./hostid
./sysctl.conf
./snmpd.config
./motd
./network/_transits
./network/_interfaces
./network/.LOCAL.swp
./network/_interface-gitoyen
./network/_mac