Gitoyen - Howto NanoBSD quagga router

Dernières nouvelles

Depuis 2001, l’année de sa création, Gitoyen a relativement peu évolué. Il y a six mois, une équipe s’est constituée (...)

Modification d’infrastructure

le 25 septembre 2009

Ces derniers mois, Gitoyen a vu son infrastructure de cœur grandement modifiée.

NanoBSD 7.1 @ Gitoyen

le 26 janvier 2009

Depuis quelques mois, nous utilisons NanoBsd sur quelques routeurs de bordure ou de livraison pour nos membres. Nos (...)

IPv6 débarque à Gitoyen

le 18 janvier 2008

Depuis quelques jours, Gitoyen dispose d’un fournisseur de transit capable de fournir de l’IPv6. Cette excellente (...)

Gitoyen est ouvert et accessible

le 7 novembre 2007

Gitoyen souhaite faciliter l’intégration et la participation de personnes intéressées par les question de routage et (...)

OpenBgpd & Quagga pourraient faire l’affaire

le 29 juillet 2007

Après avoir testé Xorp et OpenBgpd, il advient que Xorp ne peut pas, dans son état actuel, assurer la gestion des (...)

OpenBGPd ou Xorp, quel routeur libre pour demain ?

le 20 juin 2007

Utilisant Zebra depuis sa création, Gitoyen cherche aujourd’hui le logiciel de routage qui lui permettra de dépasser (...)

Oeron à l’étude

le 11 juin 2007

Afin de garantir une meilleure qualité de service au sein du gie, nous sommes en train de tester un logiciel qui (...)

Nouveau site de Gitoyen

le 1er juin 2007

C’est avec joie que nous vous annonçons la sortie d’un nouveau site web pour Gitoyen. Ce nouveau site, accompagné de (...)

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


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 :


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 :

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