Opérateur réseau alternatif

Dernières nouvelles

Assemblée Générale Ordinaire 2014

    le 27 mars 2014

Assemblée Générale Ordinaire 2013

    le 13 avril 2013

Gitoyen se transforme

    le 3 novembre 2011

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 (...)

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