inetdoc.net

Existe-t-il une meilleure façon d'implanter l'autoconfiguration IPv6 d'une interface réseau au niveau système ?

Mes recherches ont été infructueuses et je n'ai pas trouvé d'option adaptée pour le type inet6 ni dans les pages de manuels du fichier interfaces ni dans les exemples fournis avec le paquet ifupdown.

J'ai finalement obtenu un fonctionnement correct avec la syntaxe suivante :

# cat /etc/network/interfaces 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet6 manual
    post-up ip link set dev eth0 up

Après redémarrage, on obtient bien le résultat attendu :

# ip -6 addr ls
1: lo:  mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qlen 1000
    inet6 2a01:240:feb2:1:b8ad:ff:feca:fe02/64 scope global dynamic 
       valid_lft 2591527sec preferred_lft 604327sec
    inet6 fe80::b8ad:ff:feca:fe02/64 scope link 
       valid_lft forever preferred_lft forever

Chers lecteurs, toute proposition est la bienvenue.

Voici un nouvel article illustrant quelques fonctions de routage avancé sur les systèmes GNU/Linux : Aire OSPF et passerelles multiples.

Relativement aux pages classiques telles que celle du LARTC Routage avec plusieurs accès Internet/fournisseurs d'accès, chaque fonction introduite est accompagnée d'une analyse réseau avec une démarche de test précise.

La progression est l'autre point intéressant. On débute par la répartition de trafic sur les deux liens entre l'aire OSPF et le routeur opérateur puis les fonctions supplémentaires de tolérance aux pannes réseau viennent s'ajouter une à une ce qui permet une caractérisation pas à pas.

Les notions abordées sont tout à la fois «simples», comme l'illustration du fait que chaque paquet IP peut suivre un chemin propre au niveau réseau tout en préservant une connexion de bout en bout au niveau transport, ou plus «élaborées» comme le marquage de paquets et l'enregistrement des communications qui montrent qu'il est possible d'utiliser ces mécanismes sans nécessairement avoir recours à la traduction d'adresses. Sujet au combien polémique.

Bien entendu, toutes les relectures, les critiques et autres remarques sont les bienvenues.

La session 2011 du module Interconnexion de réseaux locaux et étendus s'est achevée la semaine passée par une grosse journée d'évaluation. Les résultats ne sont pas exceptionnels. Ils montrent combien les étudiants ont besoin de temps pour s'approprier les notions de base sur les mécanismes de fonctionnement des couches basses. Ceci-dit, c'est le propre de tout enseignant de regretter de ne pas disposer de plus de temps.

Le support utilisé lors des éditions précédentes sur le routage Inter-VLAN comprenait à la fois la présentation de la technologie, un exemple d'implémentation et une partie travaux pratiques. J'ai essayé de rendre le contenu plus digeste en séparant la présentation de l'implémentation.

• L'article Introduction au routage inter-VLAN présente les concepts élémentaires sur les réseaux locaux virtuels et le routage associé.
• Le support de travaux pratiques du même nom couvre un exemple d'implémentation utilisant des commutateurs Cisco au niveau liaison et un système GNU/Linux au niveau réseau.
• Le support Introduction au routage dynamique avec OSPF s'appuie aussi le routage inter-VLAN. Il permet de caractériser la différence entre une topologie physique étoile et une topologie logique triangle.

Avec le buzz actuel sur OpenFlow, l'utilisation de Debian GNU/Linux et des logiciels de routage comme Quagga Routing Suite au niveau Control Plane est plus que jamais d'actualité.

Si les supports listés ci-dessus vous intéressent, toutes les relectures, les critiques et autres remarques sont les bienvenues.

La nouvelle édition du support de travaux pratiques sur la configuration des fonctions réseau et la compilation du noyau Linux est en ligne. Toute relecture critique est la bienvenue !

Outre le fait de démystifier la compilation du noyau Linux auprès des étudiants, le but de ce support est de mettre en relation les fonctions réseau au sens large (routage, commutation, protocoles) et l'architecture du système d'exploitation associé à une plateforme matérielle. Avec l'évolution des architectures des équipements réseau, il est de plus en plus difficile d'identifier les fonctions qui sont traitées au niveau logiciel ou au niveau matériel. Je tente ici un rapprochement entre l'architecture d'un routeur et d'un serveur.

Dans un routeur, la couche Control Plane correspond à des fonctions purement logicielles telles que les démons de protocoles de routage par exemple. Une fois la décision logicielle d'acheminement d'un paquet vers une nouvelle destination prise, cette décision est mémorisée pour être exploitée de façon optimale par le matériel de la couche Data Plane.

C'est au niveau de cette couche Data Plane que les capacités de traitement des composants matériels sont prépondérantes dans le choix d'un équipement. Les composants doivent permettre le transit d'un maximum de flux réseau en parallèle. On parle ici de commutation de paquets et les composants spécialisés sont là pour «garantir» la bande passante par port comme le font les composants d'un commutateur de trames Ethernet au niveau liaison de données.

Lorsqu'il est question d'architecture, nous sommes bien souvent noyés dans le jargon. Forwarding Plane, Data Plane, et autres Crossbar Fabrics sont autant de noms différents pour un même principe général. Les seuls acronymes qui sont devenus à peu près standard et transversaux entre différents systèmes sont RIB pour Routing Information Base (au niveau Control Plane) et FIB pour Forwarding Information Base (au niveau Data Plane).

Challenge à 2€cts : retrouver l'algorithme proposé pour le traitement des entrées de la Forwarding Information Base dans la rubrique routage avancé des options du noyau Linux.

Maintenant, si l'on se réfère à l'architecture d'un PC datant d'une dizaine d'année, les performances ne pouvaient pas être comparables à celles de l'architecture décrite ci-dessus. En effet, chaque paquet devait transiter deux fois sur un bus partagé unique entre l'interface réseau et le processeur ; une fois à la réception et une fois à l'émission. Les évolutions dans l'architecture des serveurs ont conduit à une augmentation du nombre des cœurs et du nombre des bus. Tant et si bien qu'il est devenu légitime de se poser la question du choix entre les deux architectures lorsque le nombre d'interfaces est limité à 4 ou 8 ports.

Dans l'image ci-dessus, j'ai essayé de transposer l'architecture d'un routeur sur le modèle Nehalem utilisé dans de nombreux serveurs rackés. C'est une simplification dont le but est de montrer que le traitement de multiples flux réseau en parallèle est possible sur des chemins dédiés à cet usage. Il existe de nombreuses autres représentations possibles.

Puisque les deux familles d'architectures tendent à se «neutraliser», la différence devrait se faire sur les services proposés en plus des deux niveaux Control Plane et Data Plane. C'est ici qu'intervient le thème à la mode qui assure un bon clivage : la virtualisation. Dans un routeur, la virtualisation est généralement directement intégrée dans le système. La solution Virtual Routing and Forwarding en est un exemple chez Cisco. À l'opposé, une société comme Vyatta a bâti son portefeuille de solutions sur les fonctions de virtualisation présentes dans le noyau Linux ; le tout étant intégré dans des serveurs rackés.

On peut imaginer que lors des évolutions à venir les différences de conception sur la virtualisation vont s'estomper (une fois que KVM aura été adopté par tous les acteurs) et qu'un nouveau sujet clivant émergera. Il est donc essentiel de chercher à assimiler les mécanismes de fonctionnement du noyau Linux pour préparer cet avenir radieux ... où pas.

Lire la suite ...

Pour la formation STRI de l'université Toulouse III - Paul Sabatier, l'année universitaire 2011/2012 débute avec une nouvelle salle de travaux pratiques réseau. Le chantier qui a débuté au printemps dernier avec le câblage de 4 prises RJ45 par poste doit se terminer «bientôt» avec la livraison de deux bundles de routeurs et de commutateurs Cisco. Voici un schéma simplifié de l'architecture des salles de travaux pratiques.

Côté Debian GNU/Linux, je suis content d'être parvenu à poursuivre l'exploitation de systemimager grâce à alien. Le truc à consisté à passer par une étape intermédiaire dans la conversion des paquets .rpm en .deb. Après avoir téléchargé les paquets snapshots à l'adresse http://download.systemimager.org/~bli/systemimager/, il était impossible de faire une conversion directe du fait de l'emploi du caractère '_' dans le champ version du paquet. En passant par un paquet .tgz, la notion de version disparaît et le tour est joué.

$ fakeroot alien --to-tgz --scripts systemimager-server-4.1.99.svn4556_bli-1.noarch.rpm
$ fakeroot alien --to-deb systemimager-server-4.1.99.svn4556_bli.tgz

On répète l'opération pour tous les paquets à installer sur le système. L'exploitation de systemimager présente quelques limites qui vont certainement devenir critiques dans le futur. Seul le noyau 2.6.32 de la version stable (Squeeze) de Debian est supporté et il faut encore utiliser l'ancienne génération de grub via le paquet grub-legacy. Malgré ces limitations, systemimager conserve tous ses atouts dans la gestion d'un parc de postes de travaux pratiques. Avec l'architecture mise en place, il est possible d'enchaîner les séances de travaux pratiques système au cours desquelles la configuration des postes est sévèrement malmenée. Au début d'une nouvelle séance, la restauration de tous les postes de la salle ne dépasse pas le temps du laïus de lancement.

Pour faire dans le grandiloquent pompeux, on peut dire que le fait que l'étudiant soit à l'initiative de la restauration de son poste est l'acte pédagogique fondateur de l'enseignement système et réseau.

Lire la suite ...